Subject: Re: [quicwg/base-drafts] Replace HTTP_MALFORMED_FRAME for something simpler (#2551)

From: Dmitri Tikhonov <[email-masked]>
Date: Wed, 01 May 2019 05:28:25 -0700

These principles are only @martinthomson's proposal for now.

-- 
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/2551#issuecomment-488270372

---

From: ianswett <[email-masked]>
Date: Tue, 07 May 2019 22:10:00 +0000 (UTC)

Issue #2672 would make this frame more useful.

-- 
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/2551#issuecomment-490273330

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 07 May 2019 15:37:32 -0700

Maybe, but I still think the code is overkill. Each frame has to define what it means to be malformed, and most frames are simple enough that malforming them is only possible by getting the size wrong. 

The proposal on #2662 would mean most error become a generic FRAME_SIZE_ERROR. This is equivalent to the HTTP/2 status quo. It would help to know if current deployments find that insufficient and/or why they feel that a similar error in HTTP/3 would be insufficient so as to warrant MALFORMED_FRAME.

-- 
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/2551#issuecomment-490279745

---

From: Mike Bishop <[email-masked]>
Date: Mon, 13 May 2019 11:10:47 -0700

I'd like to hear feedback on this particularly from people who've implemented the current error code.  @dtikhonov, you nitpicked the connection to principles, but didn't express a position.  @afrind, @tatsuhiro-t, I think you have the other two?

-- 
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/2551#issuecomment-491928330

---

From: Dmitri Tikhonov <[email-masked]>
Date: Mon, 13 May 2019 11:42:11 -0700

@MikeBishop, I don't have a strong opinion on this and thus decline to take a position.

-- 
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/2551#issuecomment-491939154

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Tue, 14 May 2019 08:13:32 -0700

My h3 interop experience is quite short, but so far I haven't get any benefit from the current form of HTTP_MALFORMED_FRAME.  If the gain is small, then I prefer the simpler form such as just a single HTTP_MALFORMED_FRAME generic error or #2662

-- 
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/2551#issuecomment-492281105

---

From: afrind <[email-masked]>
Date: Wed, 15 May 2019 16:55:26 -0700

I don't know that it's been specifically useful so far, but I don't think it's hard to implement and has the potential to be useful.  If everyone wants to kill it I can live without it, plus we can say that at least once we chose the less complicated design. 

-- 
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/2551#issuecomment-492865545

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 15 May 2019 21:22:40 -0700

Not that I have a strong opinion on this, but I'd like to point out that the current design is somewhat inconsistent.

Now, three frame-level errors exist: MALFORMED_FRAME, WRONG_STREAM, UNEXPECTED_STREAM. Among the three, only MALFORMED_FRAME is being accompanied by a frame type. I am not sure if there is a good reason for MALFORMED_FRAME to be exceptional.

-- 
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/2551#issuecomment-492911076

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 May 2019 21:24:53 -0700

(Now that you mention these, I'm not sure now why WRONG_STREAM and UNEXPECTED_FRAME are different.  The frame is not expected to be on this stream, so...?)

-- 
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/2551#issuecomment-492911408

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 15 May 2019 21:28:05 -0700

(FWIW, UNEXPECTED_FRAME is generated when a frame is received on the correct stream at an unexpected moment. Though I am not sure if the distinction is important)

-- 
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/2551#issuecomment-492911933

---

From: Lucas Pardue <[email-masked]>
Date: Sat, 18 May 2019 04:09:53 -0700

Quoting myself:

> Another wrinke is: What should an endpoint do if it receives an error that references an unknown frame type? An endpoint MUST ignore unknown types, and we have these in the form of grease frame types with values that are included in the error code space.

Endpoint X receives a GREASE frame and for whatever reason decides to issue a stream error with a HTTP_MALFORMED_FRAME code that covers GREASE. Endpoint Y receives the error code, and takes this as a signal that X didn't follow the rule to ignore the frame. So it sends a connection error back?

This is an edge case yes, but I think it is another argument against declaring a very large codepoint space that is mostly useless in practice. 

-- 
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/2551#issuecomment-493668731