Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

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