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 and server 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_notify if all data has been sent? If the TCP or TLS connection is interrupted by the client or by an intermediary before the server application has transmitted all of its data, there doesn't seem to be a benefit to sending a close_notify to the client and it could also cause various delays which prohibit the server application from moving on to other work. For example, an unending streaming response would be closed by the client, in which case there is no need for a close_notify from the server.
---
Previous in thread (8 of 28): 🗣️ Sean Conner (sean (a) conman.org)
Next in thread (10 of 28): 🗣️ Alex // nytpu (alex (a) nytpu.com)