Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

[Patrick McManus <[e-mail]>]

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 <[e-mail]> 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" <[e-mail]>
> wrote:
>
>> On 19 June 2013 10:28, William Chan (陈智昌) <[e-mail]> 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.
>>
>>