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

Re: CONTINUATION Frame Size

From: James M Snell <jasnell@gmail.com>
Date: Mon, 12 Aug 2013 16:57:07 -0700
Message-ID: <CABP7RbeYZ_XG=YgHFBea5XzugHg0jr66e-4f1QkL-i-DeO+Fog@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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 Monday, 12 August 2013 23:57:54 UTC

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