W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

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

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Wed, 01 Aug 2007 03:19:28 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1185931168.7563.86.camel@henriknordstrom.net>
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

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

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


Received on Wednesday, 1 August 2007 01:19:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC