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 00:37:17 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1185921437.31051.37.camel@henriknordstrom.net>
On tis, 2007-07-31 at 22:37 +0200, Julian Reschke wrote:

> I think that's one of those unresolved issues, remember that other draft?
> RFC2616 states:
> "The ETag response-header field provides the current value of the entity 
> tag for the requested variant."
> So what would returning ETag on an empty PUT response mean in this case?

You mean in a 204? It's quite well defined imho.

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

> > In case of WebDAV I would in general recommend the use of the same ETag
> > on the resource and it's related properties etc..
> As properties and "content" can be manipulated independently, that would 
> be not optimal. In particular there are live properties who change 
> values without any write access, unfortunately (DAV:lockdiscovery).

Felt optimal when I wrote it but you are right. They live their own

> >> WRT to Content-Location: RFC2616 says in 
> >> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.14>:
> >>
> >> "The Content-Location value is not a replacement for the original 
> >> requested URI; it is only a statement of the location of the resource 
> >> corresponding to this particular entity at the time of the request."
> >>
> >> I don't think this is the case here...
> > 
> > Isn't it? To me it sounds like a 100% match.. The location of the
> > resource corresponding to this particular response entity at the time of
> > the request.
> Well, but the resource you send PROPFIND to is a *different* resource 
> from the one you get an URI for in GET-Location. Otherwise, you could 
> have used GET to retrieve the properties in the first place, right?

Well, when you have learnt the URI then you can. As demonstrated by your
second If-None-Match example in A.1.

Content-Location is a property about the response entity, not the
resource processing the request.

> That may be a good idea; we probably should make that a separate 
> RFC2616bis issue...



Received on Tuesday, 31 July 2007 22:38:21 UTC

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