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
