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

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.

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

> There is also no problem for PROPFIND to define that result may be
> cached on that URI without first issuing a GET under restricted
> conditions (i.e. at least same host as in the Request-URI) even if I
> would advice some caution there to avoid cache pollution security
> issues, and would therefore recommend to only allow the end-client to
> cache the entity for the purpose of PROPFIND alone, not "non-PROPFIND"
> GET's for the same URI (note: the restriction on host is then not
> needed).

I'm not sure I follow here.

The purpose of the proposal is to expose GETtable resources that 
previously where hidden behind PROPFIND/REPORT/SEARCH and similar 
methods. Once a client learns about these resources, they should behave 
just like any other HTTP resource....

Best regards, Julian

Received on Tuesday, 7 August 2007 12:06:18 UTC