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: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 19 Jun 2013 14:15:21 -0400
Message-ID: <CAOdDvNq76VfYnrYZDmZC5ngDEgmkPguVPWDs=O25hUvmjM_1dg@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, ChanWilliam(陈智昌) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Roberto Peon <grmocg@gmail.com>, Jeff Pinner <jpinner@twitter.com>
let's consider it this way.. has any implementation found FRAME_TOO_LARGE
to be useful (outside of the case of implementations not wanting to handle
frames > 64KB which is now not a factor)? If not, then it should go. If so,
then I guess it should stay.


On Wed, Jun 19, 2013 at 2:05 PM, James M Snell <jasnell@gmail.com> wrote:

> For now, in the implementation draft, can we keep this focused on whether
> or not to rename this one existing error code rather than expand into too
> much philosophical debate about error codes in general? We can refine the
> error code mechanism if necessary later on.
> On Jun 19, 2013 11:00 AM, "Martin Thomson" <martin.thomson@gmail.com>
> wrote:
>
>> On 19 June 2013 10:28, William Chan (陈智昌) <willchan@chromium.org> wrote:
>> > 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.
>>
>> I thought that was the reason you wanted to put the opaque stuff in the
>> body.
>>
>> The reason I'm pushing back is that it is possible to spend error code
>> bits on any amount of subdivision of the PROTOCOL_ERROR space.  Do you
>> want one for the case where someone didn't echo the bytes of a PING?
>> Or when they decide to send something else rather than continuing a
>> HEADERS block?  Or any of the many current and future
>> your-implementation-is-broken cases?  Ultimately, this just leads to a
>> blowout in error codes, to no good end.
>>
>>
Received on Wednesday, 19 June 2013 18:15:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC