Cache validation is not my expertise although I've enjoyed participating
in the banter over how to support 1 to 3 hit cache lookups of variants
which also vary ;-) This thread is certainly of interest to those of you
working in the area of cache invalidation, current in discussion and raised
by Mark Nottingham on the HTTP-WG discussion list.
One thing occurred to me. mod_ftp treats ftp 'commands' as http 'methods'.
So RETR is equivilant to a GET. His point about "and unrecognised request
methods" reminds me there is no way for a module to reflect that a method
it handled was idempotent or otherwise harmless to the ETag and content of
the cache. If your module implements PATCH, as this modifies the resource,
there is no harm since it's unrecognized by the cache. If your module
implements GET-HTML-HEAD, we have a problem since cache doesn't recognize
and your module can't inform.
It would be cool to have an idempotence flag in the next major release for
handlers/filters to say that the arbitrary method operation munged the origin,
or it did not. Thoughts?
Bill
--- Begin Message ---
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).
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.
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."
--- End Message ---
