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 [mailto:martin.thomson@gmail.com] 
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 Monday, 7 October 2013 21:31:29 UTC