W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

Re: New "200 OK" status codes, PATCH & PROPFIND

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 07 Aug 2007 13:59:26 +0200
Message-ID: <46B85E9E.7010103@gmx.de>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT