Re: [quicwg/base-drafts] Forwarding upstream error mid-body to downstream (#3300)

[Martin Thomson <[e-mail]>]

Look, I recognize the difficulty here, but I don't think that this problem suggests anything other than a (maybe) a new stream reset error code.  I realize that pushes for widening of the HTTP/3-to-transport interface, but I can't see an alternative that does not create horrible externalities for this use case.  Important as it might be for CDNs and the web, I don't think that it is a good idea to have the rest of the system bear the cost of dealing with the problem.

I am very much opposed to the proposal in #3303 for previously-stated reasons.

Enabling in-order delivery of stream resets would be a massive disruption to the protocol, even if we only did it at the HTTP/3 layer.  I don't concretely know how to do that, but it implies a significant shift (or bifurcation) in the stream model if we did it at the transport layer.

Adding in-order resets at the application layer for HTTP/3 is not trivial either.  A frame on the same stream is not going to work because it prevents an intermediary from forwarding without reframing at that layer.  Otherwise, they would not be able to guarantee that they can send any frame on the stream.  That requires a big shift in how people approach building of intermediaries.  Something on a control stream might work, but then you have the potential for ambiguity about placement relative to the target stream unless you effectively replicate the RESET_STREAM design at the application layer.  That would make me very uncomfortable.

It seems to me that you *can* address this without changing the protocol, even if it requires some awkward crossing of protocol layers.  That's my preference.

-- 
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/3300#issuecomment-566367359