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

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

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 7 Aug 2007 15:33:39 -0700
Message-Id: <A54DEAD5-EC7C-4F44-AF5D-17DE6018A5EA@gbiv.com>
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Aug 7, 2007, at 5:05 AM, Julian Reschke wrote:
> Henrik Nordstrom wrote:
>> On mån, 2007-08-06 at 23:43 +0200, Julian Reschke wrote:
>>> Cache-Control applies to the response. What the proposal is about  
>>> is to enable the server to say that
>>> (a) the response body (DAV:multistatus) is cachable for n  
>>> seconds, while
>>> (b) the substitute URL can be used for N seconds,
>> Is there really a need to time-limit the substitute URL?
> I have to admit I'm not really sure.

I don't even understand why such a thing would be useful.  All URLs
are permanent -- it is only the representations that change over time.

>> Imho this should be to an permanent alternative URL-namespace for
>> accessing the properties, existing even before the request has been
>> seen. If the URI disappeares for whatever reason the client will  
>> need to
>> fall back on PROPFIND, or whatever method is used in future to  
>> find the
>> "PROPFIND URI namespace schema".
> Yes, one could argue that a 404 response on the substitute URL is  
> the signal to go back to the original method and Request-URI.  
> However, that would mean that:
> - that we loose the ability to use 404 as in the original method  
> (such as: the resource is gone, but it may come back), and
> - it may become harder to deploy changes in the server software  
> (when the substitute URL format changes).
>> There is no problem for PROPFIND to define that this Content- 
>> Location is
>> permanent.
> ...other than RFC2616 saying it's not permanent?
> I'd really prefer not to change this.

I don't know if this is just a language issue or bad grammar within
the spec, but I know for a fact that isn't what was intended or in
practice.  What the spec is supposed to say is that the new location
is not a permanent replacement for the URI that was used in the original
request.  In other words, the recipient cannot assume that


That statement has nothing whatsoever to do with the permanence of
newURI as an identifier for the new resource.  If you just think of
how C-Loc is used most commonly -- within content negotiation -- that
should be clear.  newURI is ideally the permanent identifier for the
variant that directly corresponds to the provided representation
(as included in the entity).  In other words, Content-Location
is exactly what you want.  The only thing you need to add is a
clarification that the provided general/response-header fields are
also applicable to that Content-Location as if it had been a GET
request, but only when the security consideration regarding cache
poisoning can be reasonably avoided.

Received on Tuesday, 7 August 2007 22:33:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC