💾 Archived View for station.martinrue.com › alcatraz › 511bdfd335bc4540be185719a4d930e4 captured on 2024-12-17 at 15:02:15. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Let's all agree to fix our software so that it does not require the CR in the CRLF end-of-line mark. In other words, let's accept inputs that using only a bare NL as the end-of-line.
Once all the software has been fixed, then we can all stop sending CRs.
https://fossil-scm.org/home/ext/stop-requiring-crlf.md
This topic is relevant to the Gemini protocol specification.
Under `requests`:
The client connects to the server and sends a request which consists of an absolute URI followed by a CR (character 13) and LF (character 10).
gemini://geminiprotocol.net/docs/protocol-specification.gmi
1 week ago · 👍 lucifer_jehovah_smith
https://fossil-scm.org/home/ext/stop-requiring-crlf.md
gemini://geminiprotocol.net/docs/protocol-specification.gmi
@lufte It means that it should be ignored yes or treated as an LF.
While CR and LF are ancient leftovers, I don't see it as a problem that needs to be fixed, especially not by replacing the LF character with an NL. It's an established standard, hate it or like it, changing it over will just cause issues and a second standard. · 1 week ago
The spec also states that “since text/gemini is a subtype of MIME type "text", line breaks are therefore represented by the sequence CRLF”. I wonder if clients respect this. Does this mean that single LF characters should be ignored? · 1 week ago