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

[Lucas Pardue <[e-mail]>]

I wasn't following this discussion so closely, so IIUC the problem is that the stream cannot end abruptly or else there are no guarantess from QUIC layer that the DATA will arrive at the HTTP client. Closing cleanly would ensure DATA is delivered but triggers h3-24 section 7.1.

> If we consider that a tunnel should be allowed to send DATA frames (or HTTP/1 chunks) that it receives from upstream as is,

To invoke the problem, an intermediary would have needed to committed a DATA frame of length `N`, to stream offset `O`, then attempt to fin the stream at offset `F`, which is less than `O+N`. I can see several scenarios that this might occur in an intermediary and it would be quite unfortunate to cause a connection close.

Since request streams are the only core streams that can be cleanly closed without blowing up the connection I think the middle ground might be to state something like: an endpoint that receives truncated leading HEADERS or PUSH_PROMISE should treat it as a connection error. Truncation of DATA and non-leading HEADERS is ok. Extension frames or streams need to consider truncation and specify the behaviour.

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