W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1998

Re: ADAMS1, point 31. (cachability of methods).

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Mon, 16 Nov 1998 15:14:12 -0500
Message-Id: <3.0.5.32.19981116151412.02fdae30@localhost>
To: Jeffrey Mogul <mogul@pa.dec.com>, http-wg@hplb.hpl.hp.com
At 11:47 11/16/98 PST, Jeffrey Mogul wrote:
>My suggested fix:
>
>(1) In 13.4 change:
>
>   Unless specifically constrained by a cache-control (section 14.9)
>   directive, a caching system MAY always store a successful response
>   (see section 13.8) as a cache entry, MAY return it without validation
>   if it is fresh, and MAY return it after successful validation.
>
>to:
>
>   Unless specifically constrained by a cache-control (section 14.9)
>   directive, a caching system MAY always store a successful response
>   (see section 13.8) to a GET or HEAD request
>   as a cache entry, MAY return it without validation
>   if it is fresh, and MAY return it after successful validation.
>   A caching system MUST NOT treat responses to other methods
>   as cachable (by the definition in section 1.3) unless the
>   response includes Cache-Control or Expires header fields
>   implying that the response is cachable.

This doesn't work with the wording in section 13.11 which I am basing the 
cache interactions for the M- methods used by the HTTP Extensions
Framework on:

All methods that might be expected to cause modifications to the origin 
server's resources MUST be written through to the origin server. This 
currently includes all methods except for GET and HEAD. A cache MUST NOT 
reply to such a request from a client before having transmitted the request 
to the inbound server, and having received a corresponding response from the 
inbound server. This does not prevent a proxy cache from sending a 100 
(Continue) response before the inbound server has sent its final reply.

The alternative (known as "write-back" or "copy-back" caching) is not 
allowed in HTTP/1.1, due to the difficulty of providing consistent updates 
and the problems arising from server, cache, or network failure prior to 
write-back.

The latest draft of the HTTP Extension Framework is available at

http://info.internet.isi.edu:80/in-drafts/files/draft-frystyk-http-extensions-01.txt

I don't mind that the request to the origin server is made conditional
but it must not be served without having been forwarded to the origin
server.

Henrik

--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk
Received on Monday, 16 November 1998 20:14:34 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:25 EDT