Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

One can't know that a frame is too small, though, unless there is a time
limit or other constraint on the sending of the frame.
Even then, packet loss can make the end of a frame disappear.

Is there a real case where frame size too small could be emitted with
confidence?
On Jun 19, 2013 7:58 AM, "James M Snell" <jasnell@gmail.com> wrote:

> FRAME_SIZE_ERROR allows us to easily deal with both over and under sized
> frames with no additional complexity or weirdness.
> Overuse of PROTOCOL_ERROR will not be a good thing long term.
> On Jun 19, 2013 7:44 AM, "David Morris" <dwm@xpasc.com> wrote:
>
>>
>>
>> On Wed, 19 Jun 2013, Patrick McManus wrote:
>>
>> > On Wed, Jun 19, 2013 at 2:00 AM, James M Snell <jasnell@gmail.com>
>> wrote:
>> >
>> > > https://github.com/http2/http2-spec/issues/140
>> > >
>> > > Currently, we have the FRAME_TOO_LARGE error code...
>> > >
>> > > suggestion is to remove FRAME_TOO_LARGE entirely and just use
>> > > PROTOCOL_ERROR
>> > yes, let's do that! FRAME_TOO_LARGE's purpose was when the frame
>> exceeded
>> > client capacity - not for malformed packets. With the new smaller frame
>> > sizes that bit of complexity can and should just go away.
>>
>> I think more information on error conditions is almost always better. The
>> recipient should always beable to fold multiple codes into one if they
>> insist.
>>
>> In any case, I haven't seen a discussion on the list, but at the interim
>> meeting, the maximum was pushed up to HTTP while allowing the framing
>> layer to retain the 64k limit implied by the field size. That seems to
>> me to mean that the http layer could still need to send the TOO_LARGE
>> error.
>>
>>