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

Re: Header Size? Was: Our Schedule

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Fri, 30 May 2014 17:34:18 +1000
Message-ID: <CACweHNBtjc5w3dnRsyASFNpNMnTMQJd4BrwygGvEEhbn-ZBjyQ@mail.gmail.com>
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Cc: David Krauss <potswa@gmail.com>, Martin Thomson <martin.thomson@gmail.com>, "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 30 May 2014 16:51, "Martin J. Dürst" <duerst@it.aoyama.ac.jp> wrote:

> 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.
>
>
If you send SETTINGS_HEADER_TABLE_SIZE=0 and a HEADERS with [0x30,0x20] in
the first block fragment you effectively disable the context, and are left
with only Huffman coding (which has a per-frame context).

As Roberto reminded me yesterday, the thing about a header block is that
when it ends, you get everything else in the reference set (carried over
from the previous header block). The biggest gain in HPACK compression
comes from not actually sending identical headers again and again, which
means not only sharing context between multiple frames, but between frames
from multiple streams. I don't know if, in practice, any per-frame
compression scheme would come close to HPACK's connection-based delta
compression, and that would be a big hit to the protocol's appeal.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/
Received on Friday, 30 May 2014 07:34:46 UTC

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