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

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

    PROPFIND oldURI  ==  PROPFIND newURI

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.

....Roy

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