Re: Indexing new entry with a size greater than SETTINGS_HEADER_TABLE_SIZE

On Thu, Aug 29, 2013 at 6:43 AM, Roberto Peon <grmocg@gmail.com> wrote:

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

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



> -=R
>
>
> On Wed, Aug 28, 2013 at 1:31 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> On 28 August 2013 13:13, Roberto Peon <grmocg@gmail.com> wrote:
>> > 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?
>>
>
>