In the nearly two years of running a gopher server the most annoying aspect of the
in my opinion,
is the inability to redirect client requests.
It's painful to see the same request for
/Phlog: over and over again due to an unwarranted assumption on how things are organized on my blog.
As I stated on the top page of my gopher server:
Welcome to Conman Laboratories
NOTE: RFC-1436 says this about selectors:
… an OPAQUE selector string … The selector string should MEAN NOTHING to the client software; it should never be modified by the client.
The selectors on this server *ARE OPAQUE* and *MUST* be sent *AS IS* to the server. Please note that the selectors here rarely start with a '/' character. Particularly, phlog entries start with a selector of "Phlog:"—note the lack of '/' and the ending ':'.
And yet—people assume I'm serving content up from a filesystem and therefore, a leading “/” is required.
If only gopher had a way to redirect the request, but alas …
I mean, you can kind of work a way, but that leads to the second most annoying aspect of the gopher protocol, in my opinion—the document type is an inherent part of the request! The client is told beforehand the type of data it will be requesting, unlike an HTTP request where the server tells the client the type of data being sent. Redirecting a gopher “directory” is easy—just serve up a “directory” type with the correct link. And while not ideal, redirecting a text file could also be done by sending a text file with the updated URL, but this doesn't help with automated clients (as I found out the hard way). And this won't work at all for any other non-text media types like images.
I suppose you could overload the “gopher error type” which has to be checked for anyway (one hopes) but again, that won't help with automated agents. Unless perhaps if the “gopher error type” was standardized a bit more, but good luck with that (although I could try it) …
At least I got the webbots to stop making requests …