Re: Issue 1310_CACHE

Henrik writes:

    I would like to link this to Jeff's new section on idempotent
    methods but as I haven't seen it (and don't believe I will) then
    please check for consistency in the last proposed paragraph.

As Paul Leach pointed out, section 13.10 has nothing at all to
do with idempotency; all that matters is whether the method
causes a change in the value of a resource.

It's also important to note that the purpose of the rules in
13.10 is NOT to provide perfect cache consistency when a
resource is changed; as the second paragraph of the section
states, this is impossible when there are multiple cached paths
to the origin server.  The purpose of 13.10 is to "reduce the
likelihood of erroneous behavior."

With that in mind:

Henrik proposes to change section 13.10, 1st paragraph from

   The effect of certain methods at the origin server may cause
   one or more existing cache entries to become non-transparently
   invalid. That is, although they may continue to be "fresh,"
   they do not accurately reflect what the origin server would
   return for a new request.

to

   The effect of certain methods performed on a resource may cause
   one or more existing cache entries to become non-transparently
   invalid. That is, although they may continue to be "fresh,"
   they do not accurately reflect what the origin server would
   return for a new request.

I'm not sure this helps.  It's the effect *at the origin server*
that is not necessarily visible to the caches.  However, it's
probably possible to make this a little clearer.  How about:

   The effect of certain methods performed on a resource at the origin
   server may cause one or more existing cache entries to become
   non-transparently invalid. That is, although the cache entries may
   continue to be "fresh," they do not accurately reflect what the
   origin server would return for a new request on that resource.

Henrik proposes to change section 13.10, 4th paragraph from

   Some HTTP methods may invalidate an entity. This is either
   the entity referred to by the Request-URI, or by the Location
   or Content-Location response-headers (if present).
   These methods are:

   o PUT
   o DELETE
   o POST

   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.

to

   All non-idempotent methods SHOULD invalidate a cached entity
   identified either by the Request-URI, or by a Content-Location
   header (if present).

   In order to prevent denial of service attacks, an invalidation
   based on the URI in Content-Location header MUST only be
   performed if the host part is the same as in the Request-URI.

As Paul pointed out, this is wrong, because it is based on the
wrong criteria.  However, the original language is slightly
misleading, because the phrase "may invalidate an entry" doesn't
quite match the use in the previous paragraph in 13.10:

   In this section, the phrase "invalidate an entity" means that the
   cache should either remove all instances of that entity from its
   storage, or should mark these as "invalid" and in need of a mandatory
   revalidation before they can be returned in response to a subsequent
   request.

So I'd replace:

   Some HTTP methods may invalidate an entity. This is either
   the entity referred to by the Request-URI, or by the Location
   or Content-Location response-headers (if present).
   These methods are:

with:

   Some HTTP methods MUST cause a cache to invalidate an entity. This
   is either the entity referred to by the Request-URI, or by the
   Location or Content-Location response-headers (if present).  These
   methods are:

Finally, Henrik asks:

    Also, I fail to see why the URI in a location header can invalidate
    a cached entry as written. If a resource is moved and there is a
    location header in the response, then the cached entry should be
    updated to reflect this, but this is already described in section
    13.4.

OK, let's use your example.  Suppose the effect of a POST method on
resource http://x.com/y is to move the resource to a new location
http://x.com/z.  After this operation has taken place at the origin
server, any cache entries for *either* http://x.com/y or
http://x.com/z could be bogus.  It's not clear what it would mean
to "update the cached entry to reflect this."  The safest approach
is to say "none of the cache entries for any of these URLs can
be used without revalidation."

To be frank, this whole section is (as noted above) somewhat of
a lost cause.  HTTP does not have a formal mechanism for a server
to invalidate a cache entry that isn't the Request-URI of the
current request, and there are many situations where this might
be a useful mechanism.  We should probably leave it to WEBDAV
to hack away at this, although (based on my previous research on
cache consistency in distributed file systems) I'm dubious that
any version of HTTP/1.x could actually solve the problem.

-Jeff

Received on Thursday, 31 July 1997 15:29:05 UTC