- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 07 Aug 2007 13:59:26 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
Roy T. Fielding wrote: > > On Aug 6, 2007, at 2:43 PM, Julian Reschke wrote: >> Cache-Control applies to the response. What the proposal is about is >> to enable the server to say that > > Cache-control is a general header (both a request and response header). > Its scope in a response is the same as ETag. > >> (a) the response body (DAV:multistatus) is cachable for n seconds, while >> >> (b) the substitute URL can be used for N seconds, >> >> where N >> n. >> >> So these are really different things. > > No, they aren't different things. Both refer to the same content, > with the same freshness requirements, so there is no situation in > which the resource owner would need to assign them different values. Doesn't compute for me. Example: When I do a PROPFIND on a WebDAV collection, the DAV:multistatus response body represents (in the simple case) the collection membership of that collection. That information may be cacheable, and can change frequently (if there is authoring going on). On the other hand, the substitute URL for that response (as proposed in the GET-Location proposal) has a much longer lifetime. If the lifetime would be the same, a client couldn't use GET *instead* of PROPFIND, and that was the main point of the proposal. > We simply define cache-control to apply to both and we are done. > That is exactly how I would interpret such a received response today, > that includes both content-location and cache-control, without any > changes to 2616. All we would be changing is the documentation. If the cacheability of both is the same, then it can't be used in the way the it's being proposed. Best regards, Julian
Received on Tuesday, 7 August 2007 11:59:52 UTC