Problems with CRLF

[Philip Linde]

On Thu, 05 Nov 2020 16:23:17 +0100
"Arav K." <nothien at uber.space> wrote:

> On Thu Nov 5, 2020 at 4:05 PM WAT, Adnan Maolood wrote:
> > Using CRLF to terminate response headers allows a server to get away
> > with the following response:
> >
> > 10 This META is more than one line long\n
> > I bet your client can't handle this\n
> > The end\r\n
> 
> I will check myself, but I don't think most clients would throw up when
> faced with input like this.  I thought it's a common way to present
> multi-line input prompts.  If it's not, that's also fine, but I don't
> see this being so big of an issue that the spec needs to be changed.

If there is some ambiguity, I think it should be addressed. According
to the spec, a response consists of a "single CRLF-terminated header
line". Semantically, "\n" (line feed) feeds a new line. In that sense
a response per that example contains multiple lines of which only one
is "CRLF terminated".

Because the exact definition of a line is not specified, I guess there
*is* some ambiguity. I have however assumed that META won't contain
line feeds and I think other implementers should too because it's
clearly not in the spirit of the spec that a status line should
represent more than a single line.

-- 
Philip
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201105/c0964ca9/attachment.sig>