💾 Archived View for rawtext.club › ~sloum › geminilist › 005828.gmi captured on 2023-09-28 at 17:01:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
Scot gmi1 at scotdoyle.com
Mon Mar 1 21:18:22 GMT 2021
- - - - - - - - - - - - - - - - - - -
On 2/28/21 8:48 PM, Sean Conner wrote:
I've created a few issues already, but gitlab is apparently having issues
of its own right now, so for now, the mailing list is still the place to
bring these up. Anyway, while I'm here I might as well weigh in on some of
the current proposals.
Regarding Gitlab issue #2 "TLS Close", may we ease client andserver implementations by:
1. Not requiring client applications to send TLS close_notify,since they indicate end-of-data via the request <CR><LF> ?
2. Only requiring server applications to send TLS close_notifyif all data has been sent? If the TCP or TLS connection isinterrupted by the client or by an intermediary before the serverapplication has transmitted all of its data, there doesn'tseem to be a benefit to sending a close_notify to the clientand it could also cause various delays which prohibit the serverapplication from moving on to other work. For example, anunending streaming response would be closed by the client,in which case there is no need for a close_notify from the server.