Hi all, The transaction sequence in section 1.1 seems to read chronologically, which would mean clients are not permitted to handle any of the response until the server closes the connection. Would it make sense to clarify this in the spec, maybe by changing the last line of section 1.1 or by adding a note to section 3.4? Scot
Hi,
> The transaction sequence in section 1.1 seems to read chronologically,
> which would mean clients are not permitted to handle any of the
> response until the server closes the connection.
I hadn't noticed that in my reading: it does look like incremental
processing/rendering might be strictly disallowed with response body
handling only allowed to occur after the close_notify.
> Would it make sense to clarify this in the spec, maybe by changing
> the last line of section 1.1 or by adding a note to section 3.4?
What's the current informal stance on clients just doing this given the
ambiguity in the spec? It seems a bit odd to me that the spec would
forbid this class of client optimizations: reading the whole of a
response into memory for processing feels like it could be a fairly
wasteful operation[0].
Anyway, I'm just seconding Scot's question and asking for some broader
clarification!
--
lincoln auster
they/them
0: I also think it would lead to a more complex implementation in
functional(-ish) languages where we can map a rendering subroutine
over a TLS stream regardless of the completion of that stream, but
don't quote me on that :).
Scot <gmi1@scotdoyle.com> writes: > Hi all, > > The transaction sequence in section 1.1 seems to read chronologically, > which would mean clients are not permitted to handle any of the > response until the server closes the connection. I don't know how every gemini client handle this, but IMHO the clearest way to do so is just streamingly parsing the output as soon as it arrives. If you don't get a close_notify at the end you can just as well delete the page and render an error if you want. (also, you won't be able to handle streaming pages if you wait for the server to close the connection) > Would it make sense to clarify this in the spec, maybe by changing > the last line of section 1.1 or by adding a note to section 3.4? No. The transaction sequence shows the steps, it's not written anywhere that some of those steps can't happen in parallel. > Scot
Fun story: I misunderstood this email and thought you were talking about when the server should start sending a response. That misunderstanding let me to find a bug in the server framework I'm writing that would have caused it to hang, so... thanks? -- Regards, Jonathan Lamothe Sent from my mobile device. Nov. 22, 2021 18:55:46 Scot <gmi1@scotdoyle.com>: > Hi all, > > The transaction sequence in section 1.1 seems to read chronologically, > which would mean clients are not permitted to handle any of the > response until the server closes the connection. > > Would it make sense to clarify this in the spec, maybe by changing > the last line of section 1.1 or by adding a note to section 3.4? > > Scot
...and I keep sending to this list from the wrong address. -- Regards, Jonathan Lamothe Sent from my mobile device. Nov. 23, 2021 13:11:21 Jonathan Lamothe <jlamothe@posteo.net>: > Fun story: > > I misunderstood this email and thought you were talking about when the server should start sending a response. That misunderstanding let me to find a bug in the server framework I'm writing that would have caused it to hang, so... thanks? > > -- > Regards, > Jonathan Lamothe > > Sent from my mobile device. > > Nov. 22, 2021 18:55:46 Scot <gmi1@scotdoyle.com>: > >> Hi all, >> >> The transaction sequence in section 1.1 seems to read chronologically, >> which would mean clients are not permitted to handle any of the >> response until the server closes the connection. >> >> Would it make sense to clarify this in the spec, maybe by changing >> the last line of section 1.1 or by adding a note to section 3.4? >> >> Scot
On Tue, 23 Nov 2021 08:57:43 +0100 Omar Polo <op@omarpolo.com> wrote: > Scot <gmi1@scotdoyle.com> writes: > > > Hi all, > > > > The transaction sequence in section 1.1 seems to read chronologically, > > which would mean clients are not permitted to handle any of the > > response until the server closes the connection. > > I don't know how every gemini client handle this, but IMHO the clearest > way to do so is just streamingly parsing the output as soon as it > arrives. If you don't get a close_notify at the end you can just as > well delete the page and render an error if you want. > > (also, you won't be able to handle streaming pages if you wait for the > server to close the connection) > Agreed. A nice side effect (imo) of specifying that clients are permitted to start handling requests right away is that the streaming use case is included.
On Tue, 23 Nov 2021 18:19:03 +0000 (UTC) Jonathan Lamothe <jonathan@jlamothe.net> wrote: > Nov. 23, 2021 13:11:21 Jonathan Lamothe <jlamothe@posteo.net>: > > > Fun story: > > > > I misunderstood this email and thought you were talking about when the server should start sending a response. That misunderstanding let me to find a bug in the server framework I'm writing that would have caused it to hang, so... thanks? > > > > -- > > Regards, > > Jonathan Lamothe > > Glad to be of help. I'm right there with you.
Scot <gmi1@scotdoyle.com> writes: > On Tue, 23 Nov 2021 08:57:43 +0100 > Omar Polo <op@omarpolo.com> wrote: > >> Scot <gmi1@scotdoyle.com> writes: >> >> > Hi all, >> > >> > The transaction sequence in section 1.1 seems to read chronologically, >> > which would mean clients are not permitted to handle any of the >> > response until the server closes the connection. >> >> I don't know how every gemini client handle this, but IMHO the clearest >> way to do so is just streamingly parsing the output as soon as it >> arrives. If you don't get a close_notify at the end you can just as >> well delete the page and render an error if you want. >> >> (also, you won't be able to handle streaming pages if you wait for the >> server to close the connection) >> > > Agreed. A nice side effect (imo) of specifying that clients are > permitted to start handling requests right away is that the > streaming use case is included. Exactly! :D
---