W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Header Size? Was: Our Schedule

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Fri, 30 May 2014 15:51:58 +0900
Message-ID: <53882A8E.5000908@it.aoyama.ac.jp>
To: David Krauss <potswa@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
This is just a thought:

Would it be possible to allow arbitrarily large amounts of header data 
(either via continuations or via multiple header frames), but to limit 
compression to a single header frame.

While in general, there is a stronger need to compress larger stuff, 
such a solution could come with various benefits:
- Simplified compression (less/no state)
- Keep the main benefit (quick start)
- Penalty against large amounts of header data
   (because that's not the way to do things anyway)

Regards,   Martin.

On 2014/05/29 08:54, David Krauss wrote:
>
> On 2014–05–29, at 1:23 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 28 May 2014 08:51, Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com> wrote:
>>> The following are based off yesterday's CWS traffic. ~ 6BN requests of which only 123 fall into the > 64K category. So, yes they exist but they're a tiny edge case.
>>> Header sizes in each case are rounded down to the nearest KB.
>>
>> Awesome, thanks!  If we are interested in discussing who to throw off
>> the bus, 64K seems like good break point to discuss.  Though that
>> doesn't avoid the need for continuations entirely.
>
> It does if the max frame size goes back up to 64K. It was only reduced to artificially make continuations more likely, right?
>
> As for common-case head of queue blocking, DATA frame payloads can still be limited to 16K if we like. Such a limit disparity also solves the padding granularity problem.
>
> Again I’ll suggest that nobody gets “thrown off the bus” if the canonical translation to and from HTTP/1.1 uses an initial sequence of header blocks, with routing information going into the first block.
>
>
>
Received on Friday, 30 May 2014 06:52:43 UTC

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