Re: Design: Rename FRAME_TOO_LARGE to FRAME_SIZE_ERROR

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