Re: All changes but huffman encoding integrated + a question

+1 to #1, too. I didn't run into this yet because I passed around strings
by value, but I can imagine this coming up for an optimized implementation.


On Tue, Oct 15, 2013 at 7:43 PM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

>
>
>
> On Wed, Oct 16, 2013 at 11:25 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Just wanted to let people know that the github version of the compression
>> spec includes all issues but huffman encoding (Herve and Jeff-- thanks)!
>>
>> I believe there is a potential ambiguity though, which I'm not sure if
>> people realize or care about (and so asking here before potentially
>> throwing mud in clear water)...
>>
>> When adding a new header to the header table, one must first evict
>> entries.
>> When using the indexed-name literal header representation, it is possible
>> that one may be evicting the entry that contains the name which the new
>> addition would need (and which needed to be examined in order to determine
>> the amount of space to free up in the first place).
>>
>> There are two obvious resolutions:
>> 1) Require that the name be kept in these circumstances (possibly by
>> copying somewhere (ideally into the end of the buffer)). If the storage for
>> the header table was a ring buffer, one would simply increment the '0'
>> index without copying.
>> This is my preference.
>>
>>
> +1
> I actually did this in nghttp2 implementation (well, it does not use ring
> buffer at the moment, just keep reference of entry in indexed name, so that
> I get no segmentation fault).
>
> Best regards,
>
> Tatsuhiro Tsujikawa
>
> 2) Make this illegal; This makes the encoder more complex as the encoder
>> must attempt to do this encoding and then check to see if actually fit
>> every time it does this kind of header representation.
>>
>>
>> What do people think?
>>
>> -=R
>>
>
>