Monday, September 30, 2019
I finally decided to release my gopher server software
So when I originally wrote my gopher server back in February/March of 2017, it was a hack job to just more or less server up my blog over gopher. Everything was hard coded into the codebase and making changes was annoying. So earlier this month I decided to start over and make a gopher server that someone else could potentially use. Another goal was to keep the the site functioning as is.
The hardest part was naming the darned thing,
and in the end,
I decided upon the rather plain name of port70.
I've been running it now for a few weeks and not only is it stable,
but much easier to configure, modify and serve up content.
Don't mind me, I'm just a gopher pretending to be a teapot
Almost two months ago I modified my gopher server to respond to HTTP requests with “418 I'm a teapot” and it appears to have worked! The gopher server is no longer receiving any HTTP requests.
I'm also glad that the movement to remove the 418 response code failed. I don't find it useless, as it was probably odd enough that the authors of the agents making the inappropriate requests were forced to look into response and just skip my server entirely.
So yea!
An annoying aspect of the gopher protocol
In the nearly two years of running a gopher server the most annoying aspect of the
gopher protocol,
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.
(emphasis added)
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 ':'.
Thank you.
The Management
And yet—people assume I'm serving content up from a filesystem and therefore, a leading “/” is required.
Aaaaaaaaaaaaaaaaarg!
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 …
Adding redirection to the gopher protocol
The primary gopher protocol specification 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 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 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, 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.
