Re: [quicwg/base-drafts] http deadlock with stream FIN choices (#1972)

[Mike Bishop <[e-mail]>]

@martinduke filed this issue after discussing with me; while he encountered it with HTTP/0.9 in the interop, the issue applies to HQ as well.  What the draft currently says is:

> 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.

There's no normative language, but there's an expectation that the closure will happen at the end of the request.  CONNECT is different, as noted, and (if you support CONNECT, at the very least), you have to look at the request to determine whether to expect it to be closed.

In the opposite direction, we say:
> 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.

While this text is targeted at streams being reset or FIN'd *before* the request finishes, this could reasonably be interpreted/expanded to say that servers also cannot rely upon the FIN for finding the end of the request.  I suspect that you need to process a complete request regardless of whether the stream has closed or not.

-- 
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/issues/1972#issuecomment-436484647