Hacker News new | past | comments | ask | show | jobs | submit login


There's an RFC that goes over it but basically, you open a connection, send a pathname, and then the server responds with the file, which is basically the original HTTP spec (without the GET/DELETE/etc verbs).

Oh, but it also differentiates between text and binary files. Binary files are sent as-is, text files are sent line by line with a \r\n terminator. .\r\n indicates the end of file. Leading .s must therefore be doubled. And then directories are sent in another format (type/name, path, hostname, port -- tab separated).

Which means the client has to know before hand if it's a text or binary file or directory. How does it know that? Well, there's a 1-character code at the start of the filename which gives the filetype. 0 is a file, 1 is a directory, 9 is a binary file. There are also other filetypes which will make you reminisce about the 80s (Unencoded file, BinHexed file, n3270 session, etc.

HTTP (once headers and mime types were added) is a better protocol. Maybe people pine for the days when you didn't need 2 megabytes of javascript to punch the monkey, but that's not due the underlying transport protocol.


Sounds like in this day and age you can tag everything as either 0 or 9, and leave it to the client to figure it all out.

The whole text vs binary reminds me of FTP, and most clients there defaults to requesting everything as binary transfers.

Edit: MIME is no cure-all, i wonder how many times i have seen Firefox get royally confused because the MIME type is wrong.

Even if you limit it to text/binary 0/9 you still have problems.

1. your url looks like gopher://dipstick.io/0file or gopher://watchingpaintdry.museum/9folder/file. The filetype is part of the url, but only the client is aware of it -- it's not passed to the server.

2. When using a URL, the client has one idea of the file type but it does not necessarily match what the server thinks the file type is.

2. Error messages. HTTP has a status code to indicate the file doesn't exist (or was moved, etc). Gopher can send the error message back as the payload but... is that in text format or binary format? The server has no idea what format the client expects.

Always sending binary data and using out-of-band status codes and file type just keeps life simpler.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact