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

On ons, 2007-08-01 at 02:07 +0200, Julian Reschke wrote:
> > You mean in a 204? It's quite well defined imho.
> 
> What if it's a 200 and the entity said "PUT request succeeded"?

Better to use 201 then if you want to return the ETag of the object
created.. I don't think you can return any meta about the created object
in a 200 response to PUT, unless you want to return the object itself..

Personally I consider it a specification fault that 201 should not be
used when a PUT request replaces or modifies an existing resource.
Especially so on a versioned server where the PUT actually creates new
resources besides the modified one..

> > And in this case it's even more well defined. The 207 response IS the
> > requested variant, and is the same as the 200 response to the other
> > location.
> 
> Last time we discussed this at length (something like 18 months ago), 
> the consensus was that "the request variant" is what you would get if 
> you would send a GET request with the same set of headers.
> 
> PROPFIND, after all, does *not* return a representation of the resource 
> at the Request-URI.

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

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

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

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.

Regards
Henrik