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

Roy T. Fielding wrote:
> 
> 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.

The substitute URL is created/supported by the server. In general, it 
shouldn't change. In practice, changes of server code/config *do* 
happen, which may cause the substitute URL not to be the substitute anymore.

One can argue that this shouldn't happen frequently (which I agree 
with), but the question remains whether the protocol should allow 
specifying a lifetime (or alternatively, how a client is supposed to 
find out that it needs to obtain a new substitute).

>>> 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

What I'm looking for is a way to tell the client that for subsequent 
requests

      PROPFIND oldURI == GET newURI

If the validity of this information is restricted to the "next" 
requests, it doesn't solve the problem I want to solve.

So does Content-Location allow that?

> ...

Best regards, Julian

Received on Friday, 17 August 2007 12:59:15 UTC