Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

Are either of those length requirements expressed at the http layer (I
don't think they should be if they are).
I think these are protocol errors at the session or framing layer.

On the 417 thing-- I was trying (poorly :( ) to express that http status
codes are unlikely to be useful at indicating problems at the applications
protocol layer of http/2 since that becomes ambiguous.

-=R
On Jun 19, 2013 9:32 AM, "Jeff Pinner" <jpinner@twitter.com> wrote:

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