On 28/10/2022 03:46, Cameron Kaiser wrote:
This doesn't help for the non-menu case but this is still very helpful to me running a bot. Pruning dead selectors on still existing sites in the Veronica-2 database is currently its worst implemented feature and often requires me doing manual cleanup or sometimes simply blowing away an entire site and reindexing it from scratch. This would give me a programmatic way to remove tree "limbs" at the menu level and save a lot of headache.
This made me wondering. What problem would we be trying to solve here exactly? Such "normalized error codes in port field of errors" would only be useful to bots. But then, we cannot expect all gopher servers in the world to follow this convention, meaning that bots will still need to implement some guessing logic.
In my own bots, I simply look at the entries in the menu, and if it contains at least one error item I discard the page as being unworthy (either does not exists, or is otherwise broken). Seems robust enough.
The bigger problem I have is to figure out when a text file (or any other non-menu file for the matter) does not exists, and sadly the approach we are discussing here won't help with these cases.
Another huge problem I have is selectors that were a menu and become a text file overnight, or vice-versa.
In the discussed context, maybe a saner convention would be simply: "if the file or menu does not exist, then a well-behaved server SHOULD close the connection right away, without sending back anything at all - ideally shutting the connection using a TCP RST if possible" ?
Mateusz