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: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 31 Jul 2007 20:46:30 +0200
Message-ID: <46AF8386.2020708@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Henrik Nordstrom wrote:
> On mån, 2007-07-30 at 20:19 +0200, Julian Reschke wrote:
> 
>> this is a proposal that may build a bridge between the "hidden" Web 
>> (PROPFIND/REPORT/SEARCH and similar methods), and the pure Web (GET, 
>> cache validators).
>>
>> HTML and XML versions at 
>> <http://greenbytes.de/tech/webdav/#draft-reschke-http-get-location>.
>>
>> Feedback appreciated,
> 
> 
> For me it would make more sense if ETag/Last-Modified was returned in
> the response, and the GET location of the same response resouce was
> indicated using Content-Location.

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?

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

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

> ...
> Content-Location MAY also be included to keep the two responses completely equal apart from the status code, but is redundant.
> ...

Thanks for mentioning status codes, I guess we need to say something 
about it.

> Also note that weak etags is sufficient for caching of results (end of A.1).

Understood. I didn't want to mention them over here for obvious reasons :-)

So, if we can fit this functionality into existing servers, that would 
be great. Before coming up with this particular proposal, I tried that 
and came to the conclusion that it didn't work well with how 
Content-Location is currently defined...

Best regards, Julian
Received on Tuesday, 31 July 2007 18:46:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:15 GMT