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

Re: All changes but huffman encoding integrated + a question

From: Fred Akalin <akalin@google.com>
Date: Tue, 15 Oct 2013 21:25:25 -0700
Message-ID: <CANUYc_QvVJ5BC=9HoLbjCs9EkTQrSErV-rpAGBHnGTR7UbvLPQ@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
+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

> 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
Received on Wednesday, 16 October 2013 04:25:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:18 UTC