Subject: #255 eviction for substitution

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Oct 2013 13:50:00 -0700

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?

---

From: Mike Bishop <[email-masked]>
Date: Mon, 7 Oct 2013 21:30:41 +0000

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

---

From: RUELLAN Herve <[email-masked]>
Date: Wed, 9 Oct 2013 16:13:00 +0000

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.

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

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 10 Oct 2013 19:23:30 +1300

> 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 wri…

Is that not a MUST ? otherwise recipients with restricted table bounds 
who evict-then-substitute would not be strictly in sync with senders who 
substitute-then-evict in all the cases where eviction point overlaps 
with substitution point. It either becomes very long-winded to explain 
the logics around why the substituted entry #0 was not evicted or an 
interoperability nightmare when bad implementations evict the wrong entries.

Amos