💾 Archived View for rawtext.club › ~sloum › geminilist › 007537.gmi captured on 2023-11-14 at 08:31:53. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Solderpunk solderpunk at posteo.net
Sun Nov 7 15:50:09 GMT 2021
- - - - - - - - - - - - - - - - - - -
Greetings Geminauts,
I've just pushed the first changes to the official Gemini specification in close to one year! As always the official specification can be viewed at:
You can also `git clone git://gemini.circumlunar.space/gemini-site` to see individual diffs for spec changes.
A quick preamble: in the gitlab.com repos set up by Sean to work on finalising the specification, the single document form of the current official spec has been replaced by two separate documents, one for the transport protocol and one for the markup language. I think this is a good idea and I intend to adopt it for the official spec. But I also want to work carefully through the proposed changes which made it into that repo and approve or reject them individually. To facilitate this workflow it's easier for me, for now, to "backport" changes to the old format. Once I've decided I'm happy with things I'll backport as much of the new writing as proves to be applicable when translating the format. This is all a bit ugly, but it's not the end of the world. There's real value in having the diffs that actually change spec behaviour as opposed to wording/presentation be short and sweet.
Okay, I have made three changes:
1. Gemini URIs with empty paths (e.g. `gemini://example.com`) and those with paths of `/` (e.g. `gemini://example.com/`) are now equivalent by definition, and both clients and servers SHOULD normalise empty paths to `/` before sending/processing requests (along with applying other standard URI normalisations).2. The use of the TLS `close_notify` mechanism is now mandatory (see sections 1.1 and 4).3. The spec is now more explicit about clients not sending anything after a request and servers ignoring anything else they receive after a request.
You can find a little further explanation of my reasoning behind these changes in the corresponding Gitlab issues (#11, #2 and #40).
There are no major changes here. `close_notify` was in fact *already* mandatory via the TLS specs, so we are just being very explicit by repeating that in the Gemini spec. The tightened language in change three is just an attempt to close loopholes. Nobody should have been doing any of the things it prohibits anyway. If you were, you should feel bad. The biggest change is the first one. Depending on how you read RFC 3986, prior to this change it was maybe sorta technically okay for a server to serve different content from gemini://example.com and gemini://example.com/. This is no longer allowed. If you have actually been doing this you need to stop it, you strange, strange person. Both client and server authors should also update their code to normalise URIs (see section 6.2.3 of RFC 3986). Hopefully many will be able to rely on libraries to do this. If you're forced to implement this by hand, the most important normalisation in practice is also one of the simplest: replace an empty path by a `/`. This will help cut down on superfluous redirects.
Even if `close_notify` was not strictly required by the TLS RFCs, it would be logically necessary in Gemini, thanks to the lack of content length information, to disambiguate complete responses from erroneously or malisciously truncated responses. There *are* servers out there which do not reliably use `close_notify`. In principle clients visiting capsules at those servers should interpret this as something having gone wrong and e.g. notify the user or perhaps automatically retry the request. In practice client authors may wish to "be gentle" for a little longer and give server authors time to catch on to this issue before making it difficult/ugly to visit their capsules. Those who provide "torture test" services for server authors should certainly flag lack of `close_notify` as a problem.
Cheers,Solderpunk