|
On 8/12/2018 12:59 PM, Viktor Dukhovni
wrote:
Which is a change from previously required behaviour: https://tools.ietf.org/html/rfc8446#section-6.1 Each party MUST send a "close_notify" alert before closing its write side of the connection, unless it has already sent some error alert. This does not have any effect on its read side of the connection. Note that this is a change from versions of TLS prior to TLS 1.3 in which implementations were required to react to a "close_notify" by discarding pending writes and sending an immediate "close_notify" alert of their own. That previous requirement could cause truncation in the read side. Both parties need not wait to receive a "close_notify" alert before closing their read side of the connection, though doing so would introduce the possibility of truncation. I'm curious: how did this ever work for HTTPS, where for a POST request you have to see the end of the request body before you can (in general) send the response? -- Jordan Brown, Oracle Solaris |
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
