The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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.


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.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2023 by Sean Conner. All Rights Reserved.