💾 Archived View for bbs.geminispace.org › s › Gemini › 18729 captured on 2024-08-31 at 15:48:54. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-08-19)
-=-=-=-=-=-=-
Re: "0.24.0 update of Gemini Protocol is breaking a bunch of..."
I am always amazed that one can take a tiny protocol like this, and make it so complicated. It seems that it would require true brilliance to fuck it up so badly! There is hardly anything to it -- you request data and the server sends it, and gemtext has what -- 6 different types (each one delimited in a unique and difficult to parse way)... And I thought we were future proof and were not changing it!
Jul 20 · 6 weeks ago
🧇 Acidus [OP] · Jul 21 at 18:20:
I always interpreted the spec as "response lines contain a status code, a space, a meta, and a trailing CRLF. all of these fields are required." It's only later status codes that say the meta may be empty (like 20, which explicitly says "If <META> is an empty string, the MIME type MUST default to "text/gemini; charset=utf-8"". In fact no where in the spec does it ever say meta is optional. Instead the the status codes use the phrasing " The contents of <META> may contain..." At least to me, this all re-enforced the idea that the meta is always required and present, but it may be empty. Hence the space is always there.
But I'm not the designer so 🤷
🧇 Acidus [OP] · Jul 21 at 18:29:
I would also point out that Solderpunks 3 original "barebones clients", written in Go, Python, and Lua, all use code that reads a line, splits on whitespace, and acts on the fields, assuming there are 2 fields. If a space doesn't exist in the response line, all these example clients fail.
gemini://geminiprotocol.net/software/
So Solderpunks updates to 0.24.0 break their own example clients, in additional to long standing software like amfora, gemini.go, gemget, etc.
While working on Kennedy I've found capsules that send empty metas and have a single space after the status code which I wrote about here:
gemini://gemi.dev/weird.gmi
I just want it to be consistent. 0.24.0 flip flops it
🧇 Acidus [OP] · Jul 21 at 19:41:
FWIW, I emailed @solderpunk about this. I suspect this was just a mistake or typo to make the space optional. In the post:
gemini://geminiprotocol.net/news/2024_03_31.gmi
at the end it doesn't include any call outs that the 4x, 5x, or 6x responses would be changing.
📻 solderpunk · Jul 24 at 15:41:
Thanks all for bringing this to my attention. I will probably make a news post about this issue on the coming weekend.
In the comment thread here I see multiple references to a "trailing slash" but it's not clear to me what that is. Was that supposed to be "trailing space", in reference to the old behaviour for empty <META>?
0.24.0 update of Gemini Protocol is breaking a bunch of libraries and tools — The 0.24.0 update to the Gemini spec from 16.1 changes the format of the header line in a way that is breaking clients like amfora, and tools such as gemget, anything based on gemini.go, SmolNetSharp, Gemini.Net, etc. The breaking change is that, now for 4x, 5x, and 6x responses, the space between the response code and meta field is optional, and only present if there is a meta field. In other words "51" is a valid...