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

Saurabh--

Thanks for this.
It looks like Firefox is getting this wrong, per my interpretation of what
is supposed to happen here.
Indeed, though poorly specified, the intent is for the name-length and
value-list-length fields, N is 8 since there are 8 bits available for
length up to the next byte boundary, and so any value under 0xFF is (or
should be) encodable on that byte.

-=R


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