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

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
>
>