Re: Indexing new entry with a size greater than SETTINGS_HEADER_TABLE_SIZE

I hear this question from time to time :)

There are two problems we need to solve here:
 1) Ensure that the size of the compression context isn't unbounded
 2) Attempt to ensure that the compressor is doing things efficiently.

I'm interested in mandating the first, but don't want to mandate the
second. What is in the spec right now suffices to deal with #1.

For case #2, it is misleading/strange to treat this specific large entry
differently as it doesn't really solve the problem-- an encoder could
encode something that is the size of the compression context, followed by
something tiny, which then forces the large object out.


-=R


On Wed, Aug 28, 2013 at 7:15 AM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

> I suggest that indexing new entry with a size greater than
>
>
> SETTINGS_HEADER_TABLE_SIZE MUST NOT be done.
>
>
>
> Here is the current wording:
>
>
> """
>
>    The addition of a new entry with a size greater than the
>    SETTINGS_HEADER_TABLE_SIZE limit causes all the entries from the
>    header table to be dropped and the new entry not to be added to the
>    header table.  The replacement of an existing entry with a new entry
>    with a size greater than the SETTINGS_HEADER_TABLE_SIZE has the same
>    consequences.
>
> """
>
> The reason is that it just brings negative effect to the compressor; it
> clears all entries in
> the header table, which would have been utilized to reduce bytes on the
> wire, and yet
> the entry itself disappears into the void. Just no gains at all.
> Trying to add the entry to the header table knowing it cannot is just a
> bug to me.
>
> It is easy for the encoder to check the required space for the new entry
> is strictly larger
> than SETTINGS_HEADER_TABLE_SIZE. And if so, just encode it in literal
> without
> indexing. For the decoder, it has to check the required room for new entry
> nonetheless
> and just return error if the size is exceeded the limit.
>
> Best regards,
> Tatsuhiro Tsujikawa
>
>