implementations MUST initiate an exchange of closure alerts before closing a connection.  A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to <del> send its closure alert, generating an "incomplete close".  Note that an implementation which does this MAY choose to reuse the session. This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all </del> <ins> send its closure alert, generating an "incomplete close".  This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has sent or received all </ins> the message data that it cares about. <del> As specified in RFC8446, any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") MUST NOT reuse that session.  Note that a premature close does not call into question the security of the data already received, but simply indicates that subsequent data might have been truncated.  Because TLS is oblivious to HTTP request/ response boundaries, it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation occurred inside a message or between messages. When encountering a premature close, a client SHOULD treat as </del> <ins> An incomplete close does not call into question the security of the data already received, but it could indicate that subsequent data might have been truncated.  As TLS is not directly aware of HTTP message framing, it is necessary to examine the HTTP data itself to determine whether messages were complete.  Handing of incomplete messages is defined in incomplete.messages. When encountering an incomplete close, a client SHOULD treat as </ins> completed all requests for which it has received as much data as <del> specified in the Content-Length header. </del> <ins> specified in the header or, when a of chunked is used, for which the terminal zero-length chunk has been received.  A response that has neither chunked transfer coding nor Content-Length is complete only if a valid closure alert has been received.  Treating an incomplete message as complete could expose implementations to attack. </ins> <del> A client detecting an incomplete close SHOULD recover gracefully.  It MAY resume a TLS session closed in this fashion. </del> <ins> A client detecting an incomplete close SHOULD recover gracefully. </ins> Clients MUST send a closure alert before closing the connection. <del> Clients which are unprepared to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side. </del> <ins> Clients that do not expect to receive any more data MAY choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on the server side. </ins> Servers SHOULD be prepared to receive an incomplete close from the client, since the client can often determine when the end of server <del> data is.  Servers SHOULD be willing to resume TLS sessions closed in this fashion. </del> <ins> data is. </ins> Servers MUST attempt to initiate an exchange of closure alerts with the client before closing the connection.  Servers MAY close the