Interaction of FIN and message parsing (#2003)

* FIN is irrelevant

* Close is end, consume partials

* Apply suggestions from code review

* Add a MUST, call out CONNECT

* Which unless?

draft-ietf-quic-http.md

@@ -864,20 +864,28 @@ details.
 The "chunked" transfer encoding defined in Section 4.1 of {{!RFC7230}} MUST NOT
 be used.
 
-Trailing header fields are carried in an additional header block following the
-body. Senders MUST send only one header block in the trailers section;
-receivers MUST discard any subsequent header blocks.
+Trailing header fields are carried in an additional HEADERS frame following the
+body. Senders MUST send only one HEADERS frame in the trailers section;
+receivers MUST discard any subsequent HEADERS frames.
 
 A response MAY consist of multiple messages when and only when one or more
 informational responses (1xx, see {{!RFC7231}}, Section 6.2) precede a final
 response to the same request.  Non-final responses do not contain a payload body
 or trailers.
 
 An HTTP request/response exchange fully consumes a bidirectional QUIC stream.
-After sending a request, a client closes the stream for sending; after sending a
-final response, the server closes the stream for sending and the QUIC stream is
-fully closed.  Requests and responses are considered complete when the
-corresponding QUIC stream is closed in the appropriate direction.
+After sending a request, a client MUST close the stream for sending.  Unless
+using the CONNECT method (see {{the-connect-method}}), clients MUST NOT make
+stream closure dependent on receiving a response to their request. After sending
+a final response, the server MUST close the stream for sending. At this point,
+the QUIC stream is fully closed.
+
+When a stream is closed, this indicates the end of an HTTP message. Because some
+messages are large or unbounded, endpoints SHOULD begin processing partial HTTP
+messages once enough of the message has been received to make progress.  If a
+client stream terminates without enough of the HTTP message to provide a
+complete response, the server SHOULD abort its response with the error code
+HTTP_INCOMPLETE_REQUEST.
 
 A server can send a complete response prior to the client sending an entire
 request if the response does not depend on any portion of the request that has
@@ -888,13 +896,6 @@ response, and cleanly closing its stream. Clients MUST NOT discard complete
 responses as a result of having their request terminated abruptly, though
 clients can always discard responses at their discretion for other reasons.
 
-Changes to the state of a request stream, including receiving a QUIC
-RESET_STREAM with any error code, do not affect the state of the server's
-response. Servers do not abort a response in progress solely due to a state
-change on the request stream.  However, if the request stream terminates without
-containing a usable HTTP request, the server SHOULD abort its response with the
-error code HTTP_INCOMPLETE_REQUEST.
-
 
 ### Header Formatting and Compression {#header-formatting}