W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

From: James M Snell <jasnell@gmail.com>
Date: Wed, 19 Jun 2013 10:34:38 -0700
Message-ID: <CABP7RbfNJsC9LpxwQW5YyUYxf1jOpKS94AqV-aMrqZj7O_u1_A@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
+1... overloading PROTOCOL_ERROR is very very bad.

On Wed, Jun 19, 2013 at 10:28 AM, William Chan (陈智昌)
<willchan@chromium.org> wrote:
> On Wed, Jun 19, 2013 at 10:22 AM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> On 19 June 2013 09:32, Jeff Pinner <jpinner@twitter.com> wrote:
>> > 1 byte per data frame is completely legal at both the framing layer and
>> > the
>> > application layer. I believe the only illustrating examples here are
>> > something like sending a 7 byte PING frame or a 3 byte WINDOW_UPDATE
>> > frame.
>> > You have received the entire frame, it is just malformed.
>>
>> So, I have a question:  is there an actionable difference between
>> FRAME_SIZE_ERROR and PROTOCOL_ERROR.  Noting that neither RST_STREAM,
>> nor GOAWAY, have a way to indicate which frame was in error, there
>> isn't much that is actionable in either case.  I believe that the
>> action in both cases is the same: go and debug your stack.
>
>
> Actionable difference: it tells you what part of your stack to debug.
> PROTOCOL_ERROR is terrible :( Everytime we generate a PROTOCOL_ERROR, we
> have felt we wanted to add a debug string (that opaque byte sequence we
> discussed earlier) so we could figure out what was wrong.
>
>>
>>
>> That leads me to conclude that this is error code proliferation for no
>> good reason.
>>
>
Received on Wednesday, 19 June 2013 17:35:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:13 UTC