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

[Mike Bishop <[e-mail]>]

> In either case, the close signal never overtakes the partial payload.

This is not true, or at least not universal.  It's entirely legitimate for a TCP stack to dump anything that's in buffers (unread by the application) and immediately surface the TCP RST.  The reset can and does overtake partial payload in places.

> We already allow a HTTP tunnel to send a malformed response (see [the third paragraph of section 4.1.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-4.1.3-3)). That tunnel might be coalescing HTTP messages going to different endpoints. That means that an endpoint should not handle a stream that contains invalid DATA frames as a connection-level issue.

That's not my understanding of that paragraph.  It says that if an intermediary receives a malformed response, it MUST NOT forward it and MUST treat receipt of the malformed response as a stream error.  This is unclear in two ways we need to correct:

- First, it doesn't say whether the specified error should be sent upstream or downstream.  I believe this intends to say it resets the upstream stream that sent it a malformed response.
- Second, assuming the first answer, it doesn't specify what to send downstream _instead_ of forwarding the malformed response.

I would propose that we need YAEC to signal an aborted response upstream.

The suggestion that we send as much as we can, then cleanly terminate the stream disturbs me.  I'm inclined to take a hard line here and keep the text that intermediaries shouldn't be forwarding known broken responses.  That way lies consistency bugs.  You forward data as long as it's valid; if it becomes invalid, then you forward a RESET_STREAM that indicates the upstream is no longer talking sense.

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