for completeness, include the redundant RFC2818 requirements that are…

… already summarized, to be deleted later

draft-ietf-httpbis-messaging-latest.xml

@@ -1996,6 +1996,33 @@ https://www.example.org
    itself (specifically the Content-Length header) to determine whether
    the truncation occurred inside a message or between messages.
 </t>
+<t>
+   When encountering a premature close, a client &SHOULD; treat as completed
+   all requests for which it has received as much data as specified in the
+   Content-Length header.
+</t>
+<t>
+   A client detecting an incomplete close &SHOULD; recover gracefully.  It
+   &MAY; resume a TLS session closed in this fashion.
+</t>
+<t>
+   Clients &MUST; send a closure alert before closing the connection.
+   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.
+</t>
+<t>
+   Servers &SHOULD; be prepared to receive an incomplete close from the client,
+   since the client can often determine when the end of server data is.
+   Servers &SHOULD; be willing to resume TLS sessions closed in this
+   fashion.
+</t>
+<t>
+   Servers &MUST; attempt to initiate an exchange of closure alerts with
+   the client before closing the connection. Servers &MAY; close the
+   connection after sending the closure alert, thus generating an
+   incomplete close on the client side.
+</t>
 </section>
 
 <section title="Upgrade" anchor="header.upgrade">