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

Re: Header Compression...

From: Michael Sweet <msweet@apple.com>
Date: Thu, 15 Aug 2013 15:30:43 -0400
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-id: <51E38565-292A-49AD-B0FA-588299C53764@apple.com>
To: James M Snell <jasnell@gmail.com>
James,

Aside from still having concerns about the timestamp encoding, it isn't clear from the draft how you would update an existing index's value but leave the name unchanged, e.g., sending a new :path header.

>From prior discussions (and I admit I don't know if I am confusing your proposal with the other header compression) I seem to remember that sending an empty name would do the trick???

For example, indexed literal for ":path=/" encoding for slot 3 would be:

    0x40 0x03 0x05 ":path" 0x01 "/"

and then for a follow-up request to get /favicon.ico you'd use:

    0x40 0x03 0x00 0x0c "/favicon.ico"

Or am I remembering wrong?


On Aug 14, 2013, at 3:33 PM, James M Snell <jasnell@gmail.com> wrote:

> Based on feedback I have received offlist and implementation
> experience, I have made a few additional modifications to the proposed
> alternative "Stored Header Encoding" draft.
> 
>  http://www.ietf.org/id/draft-snell-httpbis-bohe-13.txt
> 
> This offers a significantly less-complex alternative to the current
> Header Compression mechanism at the cost of a few additional bits on
> the wire. The changes I have made to this draft include combining
> "Literal Replacement" and "Literal Incremental" into a single
> representation. I also made a few editorial improvements here and
> there.
> 
> As always, comments and feedback are definitely welcome.
> 
> - James
> 
> On Tue, Aug 6, 2013 at 11:49 AM, James M Snell <jasnell@gmail.com> wrote:
>> Here is an updated version of the Stored Header Encoding proposal that
>> includes the Typed Codecs.
>> 
>> http://www.ietf.org/id/draft-snell-httpbis-bohe-12.txt
>> 
>> I want to "officially" get this on the table as a proposed alternative
>> to the current header compression mechanism.
>> 
>> This really exists in two parts:
>> 
>> 1. The type codecs (which can live equally well in the current header
>> compression mechanism)
>> 2. The alternative header block encoding.
>> 
>> 
>> On Tue, Aug 6, 2013 at 9:43 AM, James M Snell <jasnell@gmail.com> wrote:
>>> While I was, unfortunately, unable to get my http/2 client
>>> implementation ready in time for the berlin interop testing, I was
>>> able to take time over the last month to dig into the header
>>> compression implementation in greater detail and I would have to say
>>> that while I agree that the current design offers a great compression
>>> profile and is technically sound for what it offers, I am definitely
>>> -1 on adopting the currently defined scheme as is without making
>>> significant changes. There are a number of reasons for this position
>>> that I've talked about a few times already so I won't get into those
>>> again.
>>> 
>>> For one, as my experimentation with the Stored Header Encoding and
>>> typed codecs demonstrates, it is possible to achieve good compression
>>> ratios using a much less complicated mechanism that is more "routing
>>> friendly", more streaming-based, has better support for ordered values
>>> (see Julian's recent comments on multi-valued header fields), has
>>> stronger memory consumption constraints and is easier to implement.
>>> Granted, we end up sending a few more bytes over the wire but that's
>>> OK, IMHO. Sending those few additional bytes is far better, in my
>>> opinion, than significantly increasing the implementation complexity
>>> of the protocol through seemingly endless premature optimization
>>> (repeat after me, "Perfect is the enemy of good"...)
>>> 
>>> In my opinion, the differential encoding and the reference set both
>>> ought to go away; the more efficient typed codecs ought to be
>>> introduced; and the header table ought to be limited to 256 storage
>>> slots so that index positions never require more than a single octet
>>> to represent on the wire. We can keep incremental and substitution
>>> indexing... In other words, some variation of what I have proposed in
>>> http://tools.ietf.org/html/draft-snell-httpbis-bohe-11.
>>> 
>>> Yes, I fully recognize that this approach ends up sending more bits
>>> over the wire on average, but that's ok. There are other approaches we
>>> can take (e.g. better sessions) that can address that gap.
>>> 
>>> - James
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Thursday, 15 August 2013 19:31:39 UTC

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