Basic file server for Mercury protocol
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
sloum ab2d5a95e7 Adds readme 2 years ago
.gitignore Updates to working/tested fileserver 2 years ago
README.md Adds readme 2 years ago
config.go.def Updates to working/tested fileserver 2 years ago
main.go Updates to working/tested fileserver 2 years ago

README.md

𐌕𐌖𐌓𐌌𐌑 (turms)

Turms was the Etruscan equivalent of Mercury (as found in Roman mythology). It seemed a fitting choice for the first Mercury protocol server implementation. Essentially you are looking at a stripped back version of the Molly Brown gemini server.

This server is meant to do one thing: serve files. There is no CGI, the status responses are terse and give away little of the server state/architecture, and there is no logging to file (though stdout does get prints of the URLs that are requested - but not IP info from the requestor). Configuration is done in Go and compiled. To change your config, just recompile.

Dependencies

A Go compiler. Anything from 1.11 onward should do nicely. There are no other dependencies.

Features

  • Serves files
  • Serves redirects for directory requests that do not include a trailing slash
  • Supports configurable serving of content from user directories
  • Configurable default file format
  • Configurable index files

Note: turms does not serve an automatically generated directory listing

To do

  • Add support for virtual hosting
    • Multiple hosts serving distinct content from a single machine
    • Each host should have individual configuration options
      • This should include distinct user foler structures
  • Add support for host aliasing

How to use

At present I have only tried it out over localhost. However, it should be as simple as filling out your config, compiling, and running turms (likely as a system service - you may need to adjust your firewall settings).

Mercury?

The Mercury protocol is/was a thought exercize proposed by solderpunk in light of the gemini protocol getting heavier over time. Mercury is an ultralight protocol just barely bigger than gopher in scope. I would say it sits between gopher and gemini.

Mercury is meant to serve up text/gemini documents, but only officially supports link lines. All other text is treated the same as it is in gopher: as plain litteral text. Clients can decide how they want to deal with lines that go longer than their window width, but are not to reflow lines - though wrapping is acceptable as need be.

Turms only supports single digit status codes:

  • [1] Query (since turms does not support CGI this will never be returned by the server, but is a part of Mercury)
  • [2] Success
  • [3] Redirect
  • [4] Server Error
  • [5] Invalid Request

As notes, turms does not support queries/cgi. Server errors should be thought of as temporary and not having to do with the request. Request errors should be thought of as potentially long term - likely something does not exist or there are not permissions to view it. Terms is terse in its error explanations. Other servers may provide more detailed messaging than the above.

There is no TLS or other security. This is 'in the clear' communication, so be aware.