Re: I-D ACTION:draft-reschke-http-get-location-00.txt

Henrik Nordstrom wrote:
> ...
> It's a bit special indeed as it doesn't act on the requested resource
> itself.. For PROPFIND the requested variant is clearly the PROPFIND
> results which is different from the request-URI resource..
> ...

My understanding was that the requested variant is independent of the 
request method.

We really need to clarify this.

>> Maybe we should focus on 
>> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i69>, then?
> 
> Or alternatively on the faults of WebDAV and how it does not fit the
> HTTP cache model very well? Also applies to CalDAV, or any other
> extension adding new "GET-like" methods to be used on the same
> Request-URI.
> 
> For what is in RFC2616 the "requested entity" based on GET is quite
> sane. It's not a 100% match, but close. The main exceptions is OPTIONS
> and TRACE, sharing the same problems as PROPFIND. The "solution" in
> RFC2616 is "Responses to this method are not cacheable.", which is what
> we are trying to get away from in this discussion.
> 
> On a related note it's worth remembering that PROPFIND (or any "unknown
> method") automatically invalidates any cached objects (all variants) at
> the request-URI in caches just following RFC2616. (last paragraph of
> 13.10).

Good point. So RCF4918bis (and other specs) should state when this is 
not the case, such as for PROPFIND / REPORT / SEARCH.

>> However, the purpose of "GET-Location" is to enable the server to 
>> provide a permanent replacement URI.
> 
> Content-Location is as permanent in the this context I'd say.
> 
> Content-Location indicates the actual/original location of the entity
> contained in the message, to be used when different from the
> Request-URI, and can be used in a GET to retreive just that entity.

It seems to me that this will only work under your definition of 
"requested variant". So we really need to work on that issue.

> Note: Resources indicated by Content-Location should not be subject to
> content negotiation. This isn't spelled out in clear text in the RFC,
> but defined indirectly by the cache model which only allow one current
> entity per Content-Location per Request-URI (13.6, last paragraph), and
> also the fact that Content-Location is supposed to refer to the original
> location of where this entity can be accessed individually.

Do you think this requires a clarification in the spec?

Best regards, Julian

Received on Wednesday, 1 August 2007 08:21:23 UTC