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

Henrik Nordstrom wrote:
> On tis, 2007-07-31 at 20:46 +0200, Julian Reschke wrote:
> 
>> The problem with returning the ETag is that ETag is defined to apply to 
>> the resource at the Request-URI, which, in this case, is incorrect, right?
> 
> No. It's a cache validator for the response entity.

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?

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

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

> See also the next sentence in the same paragraph:
> 
> "Future requests MAY specify the Content-Location URI as the request-
> URI if the desire is to identify the source of that particular
> entity."
> 
> Again, entity in this context is the message entity, not the server
> resource.
> 
>>> The use of Content-Location is also needed to make use of the cache
>>> invalidation rules, allowing automatic invalidation of cached results on
>>> modifications.
>> I'm not sure I understand. Could you provide an example?
> 
> 
> Hmm.. reading the RFC again.. no the invalidation doesn't work out
> properly without further additions to the invalidation model. It doesn't
> apply fully in this case, at least not how it's written.
> 
> Would make sense if invalidations based on Content-Location were
> generalized to in invalidate the Content-Location URI if the entity seem
> to differ. Apart from making a lot of sense in the discussed case it
> also makes caching and invalidation of negotiated entities more robust
> where otherwise the cached negotiated entity Content-Location entity
> could easily get out of sync.
> 
> I.e. having something like the following in 13.10 after the list of
> methods would make great sense I think:
> 
> "Or if the response to any other method has a Content-Location header
> and the cached entity at that URI differs from the current entity at
> that URI (as would be indicated by a change in Content-Length,
> Content-MD5, ETag or Last-Modified), then the cache SHOULD treat the
> cache entry as stale."
> 
> Most of the text is copy-pasted from HEAD, where the similar action on
> the request-URI entity is a MUST.

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

Best regards, Julian

Received on Tuesday, 31 July 2007 20:37:34 UTC