Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

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.


On Wed, Jun 19, 2013 at 9:29 AM, Roberto Peon <grmocg@gmail.com> wrote:

> But that error code refers to the entire entity size, which is not the
> frame size. One could send 1 byte per frame and still get that http error
> code.
> On Jun 19, 2013 8:04 AM, "Jeff Pinner" <jpinner@twitter.com> wrote:
>
>> The HTTP limit has to do with the size of the data frames -- we want to
>> limit how much data the peer can place in a given frame to improve
>> responsiveness to events like re-prioritization.
>>
>> As an implementation you probably would not send a connection or stream
>> error on receipt of a data frame larger than 16 KB, you would just
>> internally divide the received frame into 16 KB chunks and process them in
>> sequence.
>>
>> If the http layer does need to send a "TOO_LARGE" error, it has a
>> mechanism to do so at that layer of the protocol -- 413 Request Entity Too
>> Large
>>
>>
>> On Wed, Jun 19, 2013 at 7:41 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.
>>>
>>>
>>