💾 Archived View for rawtext.club › ~sloum › geminilist › 007626.gmi captured on 2024-03-21 at 15:42:58. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
lincoln auster lincolnauster at gmail.com
Tue Nov 23 05:38:01 GMT 2021
- - - - - - - - - - - - - - - - - - -
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 incrementalprocessing/rendering might be strictly disallowed with response bodyhandling 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 theambiguity in the spec? It seems a bit odd to me that the spec wouldforbid this class of client optimizations: reading the whole of aresponse into memory for processing feels like it could be a fairlywasteful operation[0].
Anyway, I'm just seconding Scot's question and asking for some broaderclarification!
--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 :).