Re: [quicwg/base-drafts] Don't wait for FIN to process complete messages (#2003)

[Martin Thomson <[e-mail]>]

martinthomson requested changes on this pull request.



>  
 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 SHOULD close the stream for sending; after
+sending a final response, the server SHOULD close the stream for sending. At
+this point, the QUIC stream is fully closed.
+
+Changes to the state of a request stream do not directly affect message
+processing.  Endpoints MUST process complete HTTP messages without relying on
+stream closure as an end-of-message signal.  For example, servers do not abort a

This is wrong.  The statement to make is:

The end of a stream (in either direction) indicates the end of a message.
Incomplete messages can be processed, and ideally endpoints do that after receiving a complete header block.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/2003#pullrequestreview-175154084