Re: Invalidation after updates or deletions

    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?
    
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.

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

Received on Tuesday, 18 July 2006 21:19:24 UTC