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

[Kazuho Oku <[e-mail]>]

@janaiyengar Changed the title. Though I'm not sure if you like the new one. I think the only difference is that we are now talking about errors in the headers too.

@RyanAtGoogle 
> No additional complexity in HTTP/3 or QUIC? SGTM.

Yes. That true for what we have now in #3303.

Though, unfortunately, I now realize that we have the [following provision in section 7.1](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-7.1-6): When a stream terminates cleanly, if the last frame on the stream was truncated, this MUST be treated as a connection error of type H3_FRAME_ERROR._

If we consider that a tunnel should be allowed to send DATA frames (or HTTP/1 chunks) that it receives from upstream as is, forwarding them frame-by-frame to downstream, and expect things to work, then we need change this provision to so that incomplete (DATA) frames at the end of the stream would be considered as a malformed response instead of a connection-level error.

I would prefer making such a change, though I would anticipate hearing objections. Admittedly, it is an unnecessary complexity for clients, and for server deployments who control the origin. To this end, I wonder what other proxy vendors think.

@MikeBishop @LPardue WDYT?

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