Subject: Invalidation after updates or deletions

From: Mark Nottingham <[email-masked]>
Date: Mon, 17 Jul 2006 21:36:42 -0700

RFC2616 says that POST, PUT, DELETE and unrecognised request methods  
passing through a cache MUST invalidate one or more cache entries  
(depending on the values of the Location and Content-Location headers).

   http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10

In my informal (and not yet complete) testing, I've only found one  
cache implementation -- client or intermediary -- that actually does  
this. I've tried to engage various vendors, etc. to fix it, but  
haven't seen much interest.

Why is that? Is there some non-obvious impediment to implementation?  
Lazy developers?

If it doesn't see any take-up, perhaps it should be deprecated, or  
relegated to a cache extension; e.g.,

Cache-Control: no-cache, max-age-if-you-actually-invalidate=300

Thoughts?

--
Mark Nottingham     http://www.mnot.net/

---

From: Yves Lafon <[email-masked]>
Date: Tue, 18 Jul 2006 12:02:20 +0200 (MEST)

On Mon, 17 Jul 2006, Mark Nottingham wrote:

>
> RFC2616 says that POST, PUT, DELETE and unrecognised request methods passing 
> through a cache MUST invalidate one or more cache entries (depending on the 
> values of the Location and Content-Location headers).
>
> In my informal (and not yet complete) testing, I've only found one cache 
> implementation -- client or intermediary -- that actually does this. I've 
> tried to engage various vendors, etc. to fix it, but haven't seen much 
> interest.

Good, my implementation seems to behave properly (although I didn't check 
with Location and Content-Location).

In 13.10, there is also a paragraph about DoS invalidation attacks using 
fake Content-Location, and there is a assumption about "domain of control"
of URIs:

<<<
    In order to prevent denial of service attacks, an invalidation based
    on the URI in a Location or Content-Location header MUST only be
    performed if the host part is the same as in the Request-URI.
As having the same host does not mandate any kind of exclusive control 
over the content of a web server, should we downgrade this MUST in a 
SHOULD ? (or even delete it and put warning text about possible DoS 
attack)

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 18 Jul 2006 14:19:04 -0700

Perhaps I'm cynical, but I suspect one possible reason is that the
market punishes anything that lowers cache hit rates, but doesn't
punish HTTP caches that occasionally return stale data.  After all,
the latter is a rare event, and unfortunately people have become
inured to random, transient failures.  Plus I'm not sure it's feasible
to automatically test for all of the possible failure modes that
non-compliant caches could exhibit (possibly Alex Rousskov would
be more optimistic).  So: no punishment + no tests => low compliance.

    
I would be reluctant to downgrade a MUST-level requirement that was put
in place for ostensibly sound reasons, whether or not implementors
are complying.  (The IETF rules for protocol specs require interoperable
implementations, but NOT ubiquitous compliance, because otherwise entropy
would win.)

If someone could formulate an argument that this requirement is
actually wrong, then it might be worth deleting.  (Note: I would not
want to automatically equate statements of the form "I don't see a
reason for it" with actual evidence that this, or any, requirement is
not justified.)

-Jeff