3 ms·

If you'd like to know how it's worse... A gopher URL looks like: gopher://host/Xfile Where X isn't part of the path name, it's one-character file type code.

If you'd like to know how it's worse... A gopher URL looks like: gopher://host/Xfile Where X isn't part of the path name, it's one-character file type code. This code is client-side only and determine how the client downloads and interprets the file. Gopher has 2 separate ways of sending files - Binary files are sent as-is. Text/Menu files are sent line-oriented, with a CRLF after each line and a trailing . CR LF at the end. Again, the type code is on the client side and is not sent to the server.

themodelplumber 4y ago
It's uncomfortable not just to read this, but also to be reminded of so many weird protocols and schemes from way back when. It brings to mind a box where I used to work, full of forgotten hardware that never really caught on. It was fun to check it out in some ways, but when discussing the pain points there was usually an audible groan from someone nearby.
- Agamus 4y ago
  As enthusiastic as I get about 'vintage' tech, it's sobering to hear someone note the bumpy road that led us to the slick technologies we take for granted today. It sounds like you have some interesting stories to tell. Can you give an example of something that sticks out in your memory?
tgvaughan 4y ago
For me the most annoying side-effect of this is that there's no way to signify an error in the server response, or even have errors rendered sensibly. Many servers just send errors in gophermap form (type 1), which can wind up being rendered as plain text or interpreted as binary data by the client, depending on the URL. The one advantage to this approach is that you can always convince a client to show you the source of gopher://host/1index by requesting gopher://host/0index.