Subject: Indexing new entry with a size greater than SETTINGS_HEADER_TABLE_SIZE

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Wed, 28 Aug 2013 23:15:24 +0900

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

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Aug 2013 13:13:57 -0700

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
<[email-masked]>wrote:

> 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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Aug 2013 13:31:20 -0700

> I hear this question from time to time :)

I believe that the specific concern is with respect to the choice that
has been made.  The current spec says: evacuate all from the table and
emit the header, where it could simply emit the header and leave the
header table alone.

I don't see any particular reason to choose the current option over
what Tatsuhiro is (I think) suggesting, which allows implementations
to shortcut processing.  Do you have a reason that you can share?

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Aug 2013 14:43:01 -0700

That isn't what Tatsuhiro was proposing-- he was proposing that such an
object would cause an error to be emitted (and the only way to deal with
that would be to close the connection).
Even if that was what he was proposing, it is still additional complexity
(a special case) which doesn't actually solve the complete problem of
stupid encoders.
-=R

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 29 Aug 2013 10:40:34 +0900

> (a special case) which doesn't actually solve the complete problem of

I think the proposal does not add additional complexity than the current
wording.
I actually implemented both ways: current draft wording version and the
proposed one. They both have to check the entry to be added can be fit in
the table or not in anyway. In the former, it is done at the end. For the
latter, it takes place at the beginning.
I felt the latter is a bit simpler because after eliminating the
possibility that the entry does not fit in the table, we have a guarantee
that if the indexing to the header table succeeds, it means the entry to be
added is actually in the table.
The indexing was successful but the entry is not in the header table
because of size limitation is also a special case itself to me.

And yes, the proposal does not solve the efficiency problem completely. I
admit that efficiency problem  for the reasoning is not right choice for
the proposal (well, efficiency is always a difficult matter to discuss,
right..).

Best regards,
Tatsuhiro Tsujikawa

---

From: Roberto Peon <[email-masked]>
Date: Wed, 28 Aug 2013 19:15:15 -0700

Yup, Tatsuhiro is right-- it does just move the condition around (actually,
it changes the structure of the code a bit-- in my code MakeSpace() returns
a boolean indicating if it can or can't make enough space, which hid the
test. This phrasing would change that).

I still like it less, but in one special case it does better and for no
overall complexity cost.

Tatsuhiro, will you create an issue for it?
-=R

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 29 Aug 2013 13:03:12 +0900

On Thu, Aug 29, 2013 at 11:15 AM, Roberto Peon <[email-masked]> wrote:

> Yup, Tatsuhiro is right-- it does just move the condition around
> (actually, it changes the structure of the code a bit-- in my code
> MakeSpace() returns a boolean indicating if it can or can't make enough
> space, which hid the test. This phrasing would change that).
>

Sure, here it is: https://github.com/http2/http2-spec/issues/240

Best regards,

Tatsuhiro Tsujikawa