<-- back to the mailing list

Proposed minor spec changes, for comment.

epoch epoch at enzo.thebackupbox.net

Mon May 18 23:37:15 BST 2020

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

On Mon, May 18, 2020 at 10:00:56PM +0000, jan6 at tilde.ninja wrote:

May 19, 2020 12:51 AM, "Steve Ryan" <stryan at saintnet.tech> wrote:
My only concern with this is the "server's job" part. I'd rather not
have my server transform user-supplied content, even if it's something
as minor as line breaks. Apache doesn't attempt to fix invalid HTML, why
should SecretShop fix invalid text/gemini? Seems to me this should be
handled by something like the gemini vim-syntax plugin.
It also makes writing servers a bit more complicated since text/gemini
has to be treated differently from other files and actually parsed
versus being directly served up. Not the biggest deal (and you've
already admited it's tedious) but just something I noticed.
well, teeeechnically it'd have to do this for all text/* files, according to the rfc, including
plaintext and whatnot... although THAT's unlikely to happen...
I'd also be in favor of server handling it, although that is a kinda-valid point...
html doesn't count because the browsers will do their best to fix all kinds of TOTALLY BROKEN html,
you can have partial tags, no end tags for some, etc, and the browser will never tell the user your
site is a trashpile, it will just silently try its best to fix it up (even in inspect element,
you'd see the "repaired" version)...

https://tools.ietf.org/html/rfc5147#section-4.1

" In Internet messages, line endings in text/plain MIME entities are represented by CR+LF character sequences (see RFC 2046 [3] and RFC 3676 [6]). However, some protocols (such as HTTP) additionally allow other conventions for line endings."

precedent of protocols allowing for other line endings, so the gemini speccould just say the same thing that http does about line endings.

https://tools.ietf.org/html/rfc2616#section-3.7.1

" When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP."