💾 Archived View for rawtext.club › ~sloum › geminilist › 000834.gmi captured on 2020-09-24 at 02:18:09. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Steve Ryan stryan at saintnet.tech
Mon May 18 22:51:45 BST 2020
- - - - - - - - - - - - - - - - - - -
On 20/05/18 08:35PM, solderpunk wrote:
ISSUE 2:
Problem: The spec makes a big fuss about how text/gemini is
line-oriented, but does not clearly state what exactly constitutes a
line. The definition of link lines includes a <CR><LF> at the end but
it's not clear if that applies to all line types - or whether I even
meant to do this or it was a careless error.
Proposal: Actually, it turns out this is decided for us. RFC2046,
which defines the text/* MIME media type and the text/plain subtype
covers this very clearly:
---
4.1.1. Representation of Line Breaks
The canonical form of any MIME "text" subtype MUST always represent a
line break as a CRLF sequence. Similarly, any occurrence of CRLF in
MIME "text" MUST represent a line break. Use of CR and LF outside of
line break sequences is also forbidden.
This rule applies regardless of format or character set or sets
involved.
---
Since text/gemini is, well, text/gemini, it is a "text" subtype and
using anything other than CRLF means we're violating the RFCs we're
supposedly building on top of.
So, CRLF everywhere it is.
I propose it be mostly the server's job to handle this. Text editors
on different operating systems used by content authors will use
various different line break encodings which are beyond our control,
so we can't really make it the author's job. Servers can translate LF
to CRLF before sending content over the network. This way clients
only need to handle the "canonical" format, no matter what authors do.
Rationale: Don't break foundational RFCs.
Yeah, I know, this is tedious and no fun for server authors, but, well,
see above.
My only concern with this is the "server's job" part. I'd rather nothave my server transform user-supplied content, even if it's somethingas minor as line breaks. Apache doesn't attempt to fix invalid HTML, whyshould SecretShop fix invalid text/gemini? Seems to me this should behandled by something like the gemini vim-syntax plugin.
It also makes writing servers a bit more complicated since text/geminihas to be treated differently from other files and actually parsedversus being directly served up. Not the biggest deal (and you'vealready admited it's tedious) but just something I noticed.
ISSUE 4:
Problem: Name-based virtual hosting is explicitly described as being
supported in the spec, but no mention is made of SNI (Server Name
Indication, a TLS extension which puts the desired server hostname in
the TLS handshake). Without this, virtual hosting can't be made to
work reliably.
Proposal: Mandate use of SNI by clients.
SecretShop implements virtual-hosting with the assumption that clientsare using SNI, so I'm in favour.
-Steve