I finished up the #Gopher server I started writing yesterday.
Now you can "go for" my #GopherHole to see it in action
I could probably make it better by rewriting it. At 151 lines, I might at some point.
Also: The source is 5.7K while the README.md file accompanying it is is 9.0K.
@yam655 I just read your full readme and code. It's nice that I can do that so quickly! I like your creation. Well done.
You could probably relax the ASCII to allow uft8 at this point if you want. Support is extremely widespread even though it doesn't follow the latin-1 recommendation in 1436.
I've been looking at the +VIEWS support in Gopher+ since I saw the spec. One of the reasons I'm so negative toward the weird gopher-types is that there's a standard way to identify mime types, and with the mime types, the encodings.
Once I can advertise my mime types via Gopher+, I will be able to publicize that I'm using a particular encoding.
@yam655 "The Gopher protocol prevents . and .. from being a part of valid selectors." - how so? I don't see anything in the RFC that would prevent this.
It is absent from the spec, yes. Redirection is also absent from the spec.
Nothing about the spec says you need to support `..` in any way. There is no support for what a webserver would do when it gets a path with `..` in it.
It is normal for stuff like gopher://sdf.org:70/1/users/crc/other_things/.. to fail instead of supporting filesystem-style `..` logic.
The automatic hotlinking is ignoring the ".." I had added to the URL. Easy enough to add.
I couldn't provide a link to my own gopherhole, as I wrote the software. I looked for a random gopherhole, found one on sdf, then guessed wildly that you might have one there.
Nothing about the spec says ".." needs to be supported. There is no good way to support it. Other gopher servers (like the one at sdf) fail when it is present.
I suppose this is one area that needs some considerations if serving files; a gopher selector isn't necessarily a file name or path. I have several servers which use selectors that don't serve files, but where the data is generated upon request. Selectors for many of these would be problematic as filenames due to the inclusion of characters like < > and *.
Thanks! I'd heard talk of Gopher being a "feather-weight" protocol, and it was fun to explore it this way. :)
@yam655 you may enjoy sgopherd which I use. It's about the same number of lines of code (minus comments) but seems to have more features. Its written in bash.
My site runs on it: gopher://thinkmoult.com
I am a fan of a well-written shell script, and that was fun to read. (I'm also personally familiar with using basic regular expressions in `sed` instead extended or Perl-compatible because of compatibility issues with BSD sed. I saw that and felt the pain.)
You're correct in that it definitely has more features, and it does probably have fewer lines of code.
`gofor` was my first attempt at using Python 3's `asyncio`. It's pretty unrefined.
@yam655 YAY! There now! Different! :)
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!