W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: #255 eviction for substitution

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 10 Oct 2013 19:23:30 +1300
Message-ID: <525647E2.4070107@treenet.co.nz>
To: ietf-http-wg@w3.org
On 10/10/2013 5:13 a.m., RUELLAN Herve wrote:
> 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.

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.

Received on Thursday, 10 October 2013 06:23:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC