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

From: Lucas Pardue <[email-masked]>
Date: Mon, 25 Mar 2019 16:50:36 +0000 (UTC)

I remain unconvinced on the usefulness of the HTTP_MALFORMED_FRAME error code.

Draft 19 says:

>    the HTTP_MALFORMED_FRAME (0x01XX):  An error in a specific frame type.
      If the frame type is "0xfe" or less, the type is included as the
      last byte of the error code.  For example, an error in a 
      MAX_PUSH_ID frame would be indicated with the code (0x10D).  The
      last byte "0xff" is used to indicate any frame type greater than
      "0xfe".

At the core of my perspective is that the document currently mixes the use of this error between truncated frames and more-semantic-level errors eg. 
  * receiving a MAX_PUSH_ID with a value lower than a previously sent value.
  * PRIORITY (a super complicated frame)
  * SETTINGS (error with duplicate parameters). 

I'm not convinced these semantic errors are due to the frame being malformed, it is more 'misused'. Levelling up, I wonder if this error code is the best way of approaching the problems or if we could do something simpler. HTTP/2 had a HTTP_FRAME_SIZE error which was replaced by HTTP_MALFORMED_FRAME.

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.

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