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

Re: Integer Representation in header-compression-draft-03

From: Fred Akalin <akalin@google.com>
Date: Thu, 17 Oct 2013 16:33:37 -0700
Message-ID: <CANUYc_TGsyLUY5Mr9DVAOPrMqSozYGDVZq309TAHVCpXXGBhDA@mail.gmail.com>
To: "Kulkarni, Saurabh" <sakulkar@akamai.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
My reading is that N=8 implies that there are following bytes only if the
first byte is all 1s, so \159\001 is an error. \159\001 is okay only if
N=0, in which case \159 is an error.

We should probably just mandate that 1 <= N <= 8.


On Thu, Oct 17, 2013 at 4:23 PM, Kulkarni, Saurabh <sakulkar@akamai.com>wrote:

> I was debugging my server (Akamai Ghost) with Firefox nightly for draft-06
> and noticed a discrepancy with the way integer values are being represented
> in header compression. I shot an individual mail to Patrick just in case
> this is a false alarm, or people talked about this offline.
>
> So header-compression-draft-03 says:
> "The N-bit prefix allows filling the current byte. If the value is
>  small enough (strictly less than 2^N-1), it is encoded within the
>  N-bit prefix. Otherwise all the bits of the prefix are set to 1 and
>  the value is encoded using an unsigned variable length integer [1]
>  representation."
>
> For representing lengths of header values the draft-03 says its 8+ meaning
> N=8. Which corresponds to <255 values can be encoded in 1 byte. But since
> the algorithm uses the MSB for signaling whether to consume the next byte,
> henceforth N needs to be 7. This is potentially confusing. I encountered
> this issue when I received a cookie value of length 159 which can
> potentially be encoded as 1/2 bytes (which is true to all values > 128 and
> < 255).
>
> Firefox encoded this as: 159 = \159\001, but it can also be encoded as
> just \159.
>
> Please clarify the text in the draft, because +/- 1 byte can throw-off the
> compressor completely for the subsequent values.
>
> Thanks,
> Saurabh
>
>
Received on Thursday, 17 October 2013 23:34:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC