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

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

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

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

Yes.

Regards
Henrik