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

[Kazuho Oku <[e-mail]>]

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

I might argue that we *have had* that principle. [RFC 7540](https://tools.ietf.org/html/rfc8336) by default allows a client to coalesce requests going to multiple origins (assuming that the DNS lookup and the provided certificate allows that), then let the server opt-out (by sending 421). [RFC 8336](https://tools.ietf.org/html/rfc8336) and [draft-ietf-httpbis-http2-secondary-certs](https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/) talk about coalescing requests going to multiple origins. It is my understanding that we have collectively thought that coalescing connections when possible is beneficial for privacy and performance reasons (prevents leak of SNI, better network utilization by not having multiple congestion controllers between the same endpoints).

Saying that a response from one origin might disrupt responses from other origins that are coalesced on one HTTP connection will be a wind against these previous attempts.

I am not necessarily against creating a new connection per each origin (or set of origins owned by single entity). The privacy benefit will be covered by [ESNI](https://datatracker.ietf.org/doc/draft-ietf-tls-esni/), and the performance reason can be covered by something like [draft-kazuho-quic-address-bound-token](https://datatracker.ietf.org/doc/draft-kazuho-quic-address-bound-token/).

However, as I have stated, I think we need to take a principled approach on when coalescing should (or should not) happen. This includes reconsidering if it is a good idea to allow the client to coalesce by default.

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