Re:Gophie – modern gopher client for Windows, Mac, Linux
by tgvaughan on Wednesday May 18, 2022 @02:57AM
(#31419964)
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.
Re:Gophie – modern gopher client for Windows, Mac, Linux
by themodelplumber on Wednesday May 18, 2022 @02:37AM
(#31419857)
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.
Re:Gophie – modern gopher client for Windows, Mac, Linux
by Agamus on Wednesday May 18, 2022 @09:50AM
(#31422750)
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?
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.