On 16/03/2021 07:53, Ben Smyth wrote:
Further, is it reasonable for the above first end to
expect the above second end to continue processing and
sending data that would have been sent in the absence of
such a first Close Alert?
The endpoint should expect their interlocutor to ignore any data received
after the alert: Any data received after a closure alert has been received
MUST be ignored.
The endpoint should expect any data sent before raising alert close_notify
to be delivered: It is assumed that closing the write side of a connection
reliably delivers pending data before destroying the transport.
Whether an interlocutor processes data sent before alert close_notify is
seemingly not governed by the specification, which seems reasonable.
So, that doesn't directly answer that portion of my question - but
does appear to make a half-close useless, by requiring an end
to hold off sending a Close alert until after if has received all
data that the far end is expected to send.
Do I understand that right? And if so, what is the point of the
language in the RFC that appears to permit a half-close?
--
Thanks,
Jeremy
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
