On Sun, 29 Jul 2007, Roy T. Fielding wrote:
The solution is to NOT rewrite the on-disk headers when the following
conditions are true:
- The body is NOT stale (ie. HTTP_NOT_MODIFIED when revalidating)
- The on-disk header hasn't expired.
- The request has max-age=0
This is perfectly OK with RFC2616 10.3.5 and does NOT break anything.
No, it breaks the refreshing of the on-disk header with a new Date
field representing its new age. The patch would cause a prefetching
spider to fail to do its intended job of refreshing all cached entries
even when they are not yet stale, which is something that content
management systems do all the time when fronted by a caching server.
Uh, OK... So they are dependant upon having the Date/Expires header
updated, since this is the only thing that will be affected by this
patch... Stale content will be refreshed as usual.
Since you generally never know if you will be talking to the same
cache (think DNS record pointing to multiple caching hosts) I hadn't
even imagined people trying to be "clever" and forcing updates this
way since it's kind of a special case that it would work ;)
I'm especially intrigued by the fact that stuff is depending on the
Date/Expires header in a cache being exactly what it thinks it should
be, sounds kind of broken to me...
As I said before, address the problem you have by adding a directive
to either ignore such requests from abusive downloaders or to define
a minimum age for certain cached objects. HTTP does not require the
cache configuration to be that of a transparent cache -- it only
defines how a cache configured to be transparent should work.
I would really like to understand why it wouldn't work before
resorting to such solutions. Much of the response I have got on this
has been of the "it will not work" variety while people obviously
haven't read carefully enough to realise that the condition they state
won't work isn't even affected.
However, if stuff is really depending on Date/Expires being what it
thinks it is (*shiver*) then I guess there won't be any other
options...
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | [EMAIL PROTECTED]
---------------------------------------------------------------------------
* . . . . . <- Tribble Mother and Young
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
