Issue 1310_CACHE

Henrik Frystyk Nielsen (frystyk@w3.org)
Wed, 30 Jul 1997 16:06:12 -0400 

Jim, Jeff,

Referring to Issue

	http://www.w3.org/Protocols/HTTP/Issues/#1310_CACHE

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.

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.

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.

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.

Thanks,

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA