Re: Header Compression...

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