W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013


From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 12 Aug 2013 17:08:04 -0700
Message-ID: <CAP+FsNcXy0hhO-+qLVTvXNyuK1MiRskhd+_2qHqQ5dt8=i1f8A@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
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

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.
Received on Tuesday, 13 August 2013 00:08:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC