The primary gopher protocol specification [1] is totally mum on the topic of errors. The word “error” only occurs once and that just to note that the gopher type “3” is an error. So given the lack of specification, I thought I might do an experiment and see if I can't introduce the concept of “redirection” to the gopher protocol. It can hardly be thought of violating both the spirit and letter of the spec [2] if there's nothing in the spec to figuratively or literally violate.
Upon encoutering some form of error, say, a nonexistent selector, a gopher server is supposed to return an “error selector” that looks something like:
3'/Phlog:' doesn't exist!HTHTerror.hostHT1CRLF
What I'm doing is giving some structure to the “error selector.” The text portion (the bit right after the “3” and before the first tab character) will be a fixed string giving the actual error, So for a nonexistent selector, my gopher server [3] will return:
3Not foundHT/Phlog:HTgopher.conman.orgHT70CRLF
The text portion will always be “Not found” with the nonexistent selector being returned along with the hostname and port. Now, for a redirection [4], it will return
3Permanent redirectHTPhlog:HTgopher.conman.orgHT70CRLF
The text portion will always be “Permanent redirect” with the new selector being given, along with the host and port number. Doing this will allow me to even redirect a request to another gopher server. Well, as long as the gopher client understands the error text.
Using literal text strings like this isn't ideal, but it doesn't break existing clients and does give enough information in case someone sees the error (and that they speak English—which is why this isn't ideal). Also, if the number of possible errors is kept small, then explicitly checking each string isn't that much of an issue.
I can only hope other gopher servers pick up on the idea and make gopher space a little bit less annoying to use.
[1] https://www.ietf.org/rfc/rfc1436.txt
[2] http://verisimilitudes.net/2019-07-07