💾 Archived View for gemi.dev › gemini-mailing-list › 000435.gmi captured on 2023-12-28 at 15:47:15. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-11-04)
-=-=-=-=-=-=-
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 propose that response headers should be LF-terminated lines. This would remove this loophole, but should also be a backwards-compatible change as the last CR could be ignored.
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. Most 'proper' clients (i.e. not shell scripts) should have absolutely no problem dealing with this. Shell scripts will certainly have to be wary with assuming it's a single line, but even then, no biggie. Perhaps we can provide this as a Gemini torture test (if it isn't already one), as I know many clients do check against that. ~aravk | ~nothien
On Thu Nov 5, 2020 at 11:23 AM EST, Arav K. wrote: > 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. > > Most 'proper' clients (i.e. not shell scripts) should have absolutely no > problem dealing with this. Shell scripts will certainly have to be wary > with assuming it's a single line, but even then, no biggie. Perhaps we > can provide this as a Gemini torture test (if it isn't already one), as > I know many clients do check against that. I was not aware that this was a common thing to do. If it is, and it is desirable, then I agree that it should be a client torture test. It could also be mentioned in the specification so that client authors can be aware. As a side-note, are clients expected to append a colon to the end of the input prompt? I have seen some clients do that, and wasn't sure if that was a standard thing.
> As a side-note, are clients expected to append a colon to the end of the > input prompt? I have seen some clients do that, and wasn't sure if that > was a standard thing. Definitely not expected, no. Personally, I don't think it's a good idea, as input prompts can turn out like this: What is your name?: Enter your name:: Secret passcode, please.: In my opinion it's much better to just make it obvious to the user that input is being asked for, and let the server send what it chooses. makeworld
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
---
Previous Thread: Is anyone working on a libcurl PR for gemini support?