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

*the intent is that, for... N is 8.

*sigh*


On Thu, Oct 17, 2013 at 4:36 PM, Roberto Peon <grmocg@gmail.com> wrote:

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