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: Fri, 17 Aug 2007 14:58:56 +0200
Message-ID: <46C59B90.3050802@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 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

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

      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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC