💾 Archived View for rawtext.club › ~sloum › geminilist › 000960.gmi captured on 2020-10-31 at 01:57:15. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Proposed minor spec changes, for comment.

Nicole Mazzuca nicole at strega-nil.co

Fri May 22 03:02:47 BST 2020

- - - - - - - - - - - - - - - - - - -

I am a strong proponent of "follow the existing practice if there isn't good reason to change". I personally think CRLF should be recommended, but not required for content, as text/* is wont to do over HTTP; I think expecting clients to deal with any of {CR, LF, CRLF} is totally fine. However, the header should _absolutely_ end in CRLF, as every existing protocol works this way.

Nicole

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐On Thursday, May 21, 2020 5:45 PM, Matt Brubeck <mbrubeck at limpet.net> wrote:

On Thu, May 21, 2020 at 1:47 PM solderpunk solderpunk at sdf.org wrote:

Some quick experimentation with Python revealed that str.splitlines()

is, indeed, smart enough to handle CRLF, CR and LF as linebreaks.

For what it's worth, the Rust standard library is designed to work

with both LF ("\n") and CRLF ("\r\n") line endings, but not CR alone

("\r"):

https://github.com/rust-lang/rfcs/blob/master/text/1212-line-endings.md

In the discussion that led to this, there was no real support for

supporting "\r" line endings, nor for other uncommon newlines like

U+2028 LINE SEPARATOR:

https://github.com/rust-lang/rfcs/pull/1212

I think text/gemini should allow both "\n" and "\r\n". Requiring a

single style would either place a burden on content authors (on

servers that don't auto-convert line endings), or make servers more

complex and less efficient. (They would need to inspect every

text/gemini file and possibly transform it, rather than stream it

directly from disk to the network.) Meanwhile, I think client

software can handle either option fairly simply.

For the protocol header, I don't have a strong opinion. Any choice we

make is fairly easy to implement in both server and client. However, I

have a slight preference for specifying just "\n" as the header

terminator. One byte is (marginally) more efficient than two, and in

some languages it's slightly simpler to split on a single-byte

delimiter.