RE: #255 eviction for substitution

I understand that some implementations will have a static header table that should not exceed its maximum size, even temporally. That's why I put the "logically" : that makes the spec easier to write and understand, but it's fully possible to optimize the header table handling. For example, an implementation may first make room available for the new entry, then add it to the table, keeping the table size bounded.

As for explicit deletions, I did some quick testing and this has a cost compaction-wise.

From: Mike Bishop []
Sent: Monday, October 07, 2013 23:30
To: Martin Thomson; HTTP Working Group
Subject: RE: #255 eviction for substitution

Yes, except that you've possibly caused other headers to be dropped as well.  The problem with this is that the header table will, by definition, exceed the maximum memory allowed by the size of that header, which may be large.

We could also approach simplification from the other direction, by requiring drops to be explicit.  That eliminates a lot of the issues and corner cases of both sides tracking the size and trying to synchronize their implicit drops.  It also retains any benefit of substitution by allowing a drop-then-append if desired.  There's obviously a cost -- in the most naïve case, you add one or more bytes to express a drop before any new entry.  (I haven't prototyped this to see what the cost works out to be.)

It might be productive to take some time Wednesday or Thursday to gather all the compressor issues and see if we can hash out a sensible resolution.

-----Original Message-----
From: Martin Thomson []
Sent: Monday, October 7, 2013 1:50 PM
To: HTTP Working Group
Subject: #255 eviction for substitution

Herve proposes that we simplify substitution; as opposed to the suggestion to remove it (#250).

What would be the effect of having the substituted header being dropped?  Equivalent to a header that doesn't modify the table?

Received on Wednesday, 9 October 2013 16:13:58 UTC