Re: [quicwg/base-drafts] Forwarding upstream errors, and the implications (#3300)

[Kazuho Oku <[e-mail]>]

I think that this issue discusses two orthogonal problems:
* This issue was originally about how an intermediary can close a HTTP message that it has been forwarding, when that intermediary recognizes that the message being forwarded is malformed (e.g., when upstream closes the request stream mid-frame, when the amount of body provided does not match the value of content-length response header), at the same time forwarding all the content that it has received from upstream. The only approach that works is delaying the transmission of stream resets until receiving ACKs for all the data it has sent on that stream. H2 does not have the first problem because a stream reset can never overtake the delivery of other frames that have already been sent.
* The scope of an error that happens on the request stream (or the push stream). At the moment, some errors (i.e. invalid frames) are handled at connection-level, while others (i.e. malformed response) are stream-level. This is a departure from the design that we have in H2, that localizes stream-level issues to stream-level errors. Note that H2 and H3 both allow endpoints to escalate stream-level errors to connection-level.

It might be a good idea to split this issue in two; both #3303 and #3336 are attempts to address the second problem, but not the first problem.

Regarding the second problem, there are three paths:
* a) status quo
* b) go back to what H2 does - #3336 
* c) require those errors to be stream-level, forbidding promotion to connection-level - #3303 

As stated in [my previous comment](https://github.com/quicwg/base-drafts/issues/3300#issuecomment-570117390), my preference goes to #3303, as it maximizes the chance of requests being coalesced. Unless we forbid the promotion of stream-level errors to connection level (or without stating that such promotion might have negative effects), CDNs cannot allow coalescing of HTTP requests that go to different origins, as one misbehaving origin might obstruct the exchanges between the client and other origins that share the same connection. While this is not an issue for all the server deployments, it would be a backlash against our previous efforts (e.g., ORIGIN frame, secondary certificates) to maximize the chance of requests going to different origins getting coalesced, as there would be less interest in implementing these extensions from CDNs.

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