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

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.

In case of WebDAV I would in general recommend the use of the same ETag
on the resource and it's related properties etc..

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

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.

Regards
Henrik