Subject: Re: [quicwg/base-drafts] Forwarding status of errors on streams (#3303)

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Jan 2020 18:19:21 -0800

I'm with Ian on this one.  The new "MUST NOT" would force client implementations to bury a whole class of errors.

-- 
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/pull/3303#issuecomment-570104354

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 01 Jan 2020 18:57:42 -0800

@ianswett @martinthomson Am I correct in assuming that you are arguing for prohibiting tunnels to forward malformed HTTP messages (e.g., those contain prohibited header fields)?

While I can see the beauty of such design, I am uncertain if that's a good approach. Use of an HTTP header field, which is end-to-end information, might make an HTTP message malformed. I wonder if an intermediary would be capable of detecting all such misuses. One extreme case that I can think of is an HTTP extension defining a new HTTP header field, that must not be sent as a trailer. Do we want an HTTP/3 intermediary to understand all the header fields that it forwards?

-- 
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/pull/3303#issuecomment-570107754

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Jan 2020 19:18:08 -0800

I'm not suggesting that tunnels are forced to check what they forward, but that they assume responsibility for every byte they produce, forwarded or not.

An intermediary can forwards in the way you describe in that case.  But if the source produces junk, the intermediary can wear the consequences.  That doesn't mean that you have to check everything you get, but that's a call you would have to take on yourself.

The current text passes this cost on to clients in a way that will make it much harder to enforce protocol correctness at clients.  That's not healthy.

-- 
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/pull/3303#issuecomment-570109752

---

From: Mike Bishop <[email-masked]>
Date: Thu, 02 Jan 2020 10:42:09 -0800

I think our best path forward on this is to say that these errors MUST be treated as stream errors, and we retain the general policy that a stream error MAY be treated as a connection error.

-- 
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/pull/3303#issuecomment-570301375

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Jan 2020 15:37:42 -0800

I'm starting to like what @MikeBishop says here. There still is a problem that we can't restrict what a client ultimately does. If we could describe the cost of killing a connection, instead of requiring limiting the endpoint response, that might go a long way.

-- 
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/pull/3303#issuecomment-574425233

---

From: Mike Bishop <[email-masked]>
Date: Thu, 16 Jan 2020 12:14:08 -0800

Closed #3303 via #3344.

-- 
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/pull/3303#event-2955916832