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

[Mike Bishop <[e-mail]>]

In part because in HTTP/2 end-of-stream wasn't a separate thing -- it was a flag on the final header block or DATA frame.  You couldn't end a stream elsewhere (though the workaround was a zero-length DATA frame with END_STREAM set).

In a more abstract sense, there are HTTP messages which aren't sent atomically -- they develop over time, and have to be handled in a streaming fashion.  These might be streamed responses -- or requests, for a POST or a strained protocol adaptation.  CONNECT fits into this category, since the "message body" and the "response body" are essentially infinite, and in HTTP/1.1 it was unique in being totally unframed.  In HTTP/2, though, pseudo-chunked messages work exactly the same way.

To frame it differently, I don't have a problem with saying that EOS is the end of the message; I have a problem with the implication that you can wait for the entire message to arrive before you begin processing it.  *That's* the original incompatible bug that started this issue.

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