Re: CONTINUATION Frame Size

The secondary benefit of having a limit small enough to deal with
serialization delays for DATA frames is that the continuation stuff will be
regularly-enough exercised for HEADERS that we'll have confidence that it
works.
This is a significant benefit-- getting bugs out of something like this is
not a small thing in terms of importance. The overhead here is pretty
insignificant...
-=R


On Mon, Aug 12, 2013 at 4:57 PM, James M Snell <jasnell@gmail.com> wrote:

> On Mon, Aug 12, 2013 at 4:32 PM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> > On 13 August 2013 00:11, James M Snell <jasnell@gmail.com> wrote:
> >> If the END_HEADERS flag is not
> >> set, we ought to allow frame sizes up to the maximum allowed (65,535)
> >> to eliminate this additional overhead.
> >
> > Interesting observation.  Would you make the same allowance for
> > HEADERS and PUSH_PROMISE too?  Those are actually more likely to need
> > this.
> >
>
> No, I would keep HEADERS and PUSH_PROMISE as is.. I considered that,
> but we really don't want to encourage use of big headers as you say..
> a HEADERS or PUSH_PROMISE for HTTP ought to be limited to 16k and
> ought to require CONTINUATION frames for anything above that limit,
> but the CONTINUATION frames ought to be allowed to extend to 65k to
> avoid the additional encoding overhead ... this balances the concerns
> and ought not cause any problems (the code we have for parsing
> continuation frames would actually get to omit an if statement...
> ;-)...)
>
> - James
>
> > That said, I'm not certain that I want this, it seems like an another
> > set of if() statements that could be avoided.  After all, we
> > determined that the framing overhead was tolerable.  And it's not like
> > we want to *encourage* the use of big headers.
>
>