Back to Silas S. Brown's home page
Gopher protocol considered inferior
As a partially-sighted computer scientist, I'm sometimes asked for an opinion on little-known technologies that might seem to make things easier for blind or partially-sighted people. Gopher was an early-1990s alternative to the then-emerging World Wide Web, and some enthusiasts think it must be better because it is text-based. Although Gopher can deliver graphics and other files, it's usually used for plain-text files and separate lists of links. But there are problems:
- Gopher is less likely to properly display non-English languages that are not written in ASCII;
- Gopher pages seem more likely to use "ASCII art", which confuses screen readers and cannot even be skipped like HTML images can;
- Gopher pages are typically not designed to be reflowed to less than 70 columns for giant-print and small-device situations, nor to be displayed in a proportional font (the size-changing versions of my low-vision stylesheets tell Firefox's "OverbiteFF" Gopher plug-in to use a proportional font, which helps on many Gopher pages but does break some).
Enthusiasts of the Gopher protocol sometimes point to its "headerless" nature being more lightweight than the Web's HTTP which adds headers to each transaction. The rest of this page discusses this claim.
HTTP headers actually save traffic
It may be surprising that adding more
headers can save
traffic, but it can. Consider, HTTP/1.0 and HTTP/1.1 has:
- protocol-level compression---useful for all but the smallest responses, unless the file is already compressed, or unless sufficient compression is being performed on the underlying stream of packets
- partial downloads and continuation (called "byte serving" or "range requests" in HTTP 1.1)---so if a connection fails during a large download then it doesn't have to be started again from the beginning
- keep-alive and pipelining---useful when many small requests will be made in a short time
- expiry and caching information---so browsers often won't need to re-fetch something a second time (my old Web Access Gateway's CJK image server absolutely depended on this for its apparent speed; if I'd used HTTP/0.9 or Gopher to serve those images, the user experience would have been slower despite there being fewer bytes per response).
So the actual traffic-saving advantage of headerless protocols exists only for a one-off access to a single and very small file.
Headerless responses do not require Gopher
If you do need one-off access to a single very small file and would genuinely benefit from a headerless response, this can also be obtained using:
- the original "HTTP/0.9", which pre-dates Gopher and costs just 4 extra bytes---less if Gopher's oft-omitted terminating full-stop line is counted against it
- HTTP/0.9 continued to be supported by most HTTP servers in subsequent years, so if you ran a standard HTTP server (and hadn't set it to rely on a "virtual hosts" configuration or insist on HTTPS) then you could obtain headerless responses from it, without having to either run an additional server or restrict your choice of HTTP server to one that can also handle Gopher requests.
- However in 2014 HTTP/0.9 was officially made optional (RFC 7230 Appendix A) although many servers continued to support it.
- In mid-2016 support began to be removed from mainstream browsers, which would in any case not have used HTTP/0.9 unless the server forced it; requesting it from the client side requires manual control of the transfer---but now that mainstream browsers no longer support the Gopher protocol either, it's rare to be using a system that has a Gopher-capable browser but no telnet or nc, and you can write scripts to avoid having to type the full command each time. For the record, back in 1998 my Access Gateway assumed an HTTP/1 header would be sent; it would have failed if some server had sent it an HTTP/0.9 response, but I didn't notice because I never encountered an HTTP/0.9-only server even back in 1998.
- Dedicated TCP ports that return small responses, like daytime (port 13) and qotd (port 17), often run from inetd or similar. These can require no request at all, which means:
- they require fewer keystrokes than Gopher servers if you're typing into telnet or nc
- they can still be made into Gopher links (compare lynx gopher://localhost:13 with nc localhost 13 or telnet localhost 13 if your machine runs the daytime service), and they can even be made into HTTP links if the browser still displays HTTP/0.9-style responses
- they would however be discovered by anyone who runs a port probe, whereas a link that is not known to the public would require packet sniffing to see, so you probably don't want to use the "dedicated open port" approach to implement something like "poor-man's port knocking" for an SSH server---but if that's your application then you'll find the overhead of the SSH negotiations dwarfs that of an HTTP request.
If you're typing into a Telnet client by hand on a mobile phone that charges you for every byte, then it's likely that each keystroke will end up in a separate TCP packet (not to mention the echo), in which case you'd probably be better off either using an off-the-shelf HTTP browser to send the request all at once, or else using a custom port that doesn't require a request at all (if you don't mind the information also being available to anyone who runs a port probe, and you don't need to make too many different types of information available in this way).
Example custom inetd entries for small responses
# A "what is my IP address?" service on port 2 (the Python script has to be written without spaces if you want to inline it into /etc/inetd.conf
2 stream tcp nowait nobody /usr/bin/python python -c i=__import__;a=i('sys');b=i('socket');s=b.fromfd(a.stdin.fileno(),b.AF_INET,b.SOCK_STREAM);s.sendall(s.getpeername()+'\n')
# Report uptime and system load on port 3:
3 stream tcp nowait nobody /usr/bin/uptime uptime
# Serve a small text file on port 4:
4 stream tcp nowait nobody /bin/cat cat /weather.txt
I won't go into silly nationalistic squabbles about the Web being invented by a Brit working in Europe whereas Gopher was American---if anyone feels tempted to use Gopher's general inability to display non-English languages as an anti-American joke, please remember that quite a few Americans were involved in designing Unicode and other multilingual standards, so they're not all
ignorant. There are also potential political points about Gopher having had stricter licensing in its early years, but America isn't the only place with plenty of lawyers and they did eventually
GPL it. But it does seem that the Gopher protocol would fall on technical points alone, and that its enthusiasts would be better off promoting low-bandwidth and "text-friendly" websites.
All material © Silas S. Brown unless otherwise stated.