Proposed minor spec changes, for comment.

[Nicole Mazzuca]

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.