Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

On Wed, Jun 19, 2013 at 9:27 AM, Roberto Peon <grmocg@gmail.com> wrote:
> 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?

If I send a PING frame with a length field < 8... Or a PRIORITY frame
with length field < 4 ..

Either way, you're right that too small is hard to judge (and
therefore hard to justify having a "frame too small" error... which is
why I opted for the more generic "FRAME_SIZE_ERROR" to cover both
over- and under-size conditions. Either way, there's a problem with
the frame size.

- James

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

Received on Wednesday, 19 June 2013 16:34:52 UTC