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

[Martin Thomson <[e-mail]>]

> HTTP/2 is underspecified in sense that it allows any stream error to be promoted to a connection error

I think that we might disagree on this point.  Even if the spec didn't expressly include this permission, you can always reduce this to a question of local policy.  That is, my policy could be to cease communicating with a peer that fails to follow the spec.

The effect of such a policy has been beneficial in that it provides some incentive for new implementations to follow the spec.  The same policy has also been bad in those cases where this was overzealously implemented: if we can't used new frame types without explicit negotiation, that's not a great state to be in.

> even though as we agree, a stream error that might have originated from an origin cannot be promoted to a connection error

I don't think "cannot" is agreed.  We might agree on the outcome of propagating the error, but I personally don't think that we should externalize these effects even in this way.  We might highlight the possibility of problems, but if an intermediary is forwarding streams without looking at their contents, it is still ultimately responsible for the effect of their contents.  If clients decide to hold the intermediary responsible for a failing at an origin server that is invisible to them, that's still the intermediary's problem.

I'm going to suggest that we acknowledge that this is tricky and then move on.  I don't want to create another application of the Robustness Principle before we've even shipped the protocol.


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