W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i22: ETags on PUT responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 07 Jan 2008 14:24:44 +0100
Message-ID: <4782281C.7010601@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: Werner Baumann <werner.baumann@onlinehome.de>, ietf-http-wg@w3.org

Henrik Nordstrom wrote:
> ...
>> Note they are allowed in "If" headers (RFC4918).
> True, but If is not in HTTP/1.1, and is more tailored for WebDAV than
> general HTTP.

Understood; I just keep mentioning it because it's good enough for 
WebDAV clients (such as Werner's).

>> Yes. We need to resolve all these issues (weak vs if-none-match, the 
>> matching function, the "requested variant", Etag...) in a coherent way.
> The "requested variant" is pretty clear. The variant returned had the
> request been a GET request, or in case of the ETag returned by PUT a GET
> request immediately after completion of the PUT.
> And no, this do not fit entirely with WebDAV properties, but I am sorry,
> that's a WebDAV fault, not HTTP.

I'm totally happy with that clarification, but I think Roy was arguing 

> It's also clear that PUT, DELETE etc is not designed to work with
> negotiated resources, and is meant to be used on the individual resource
> location (i.e. Content-Location of a negotiated resource). However, due

Agreed. A server that supports authoring negotiated resources better 
supply URIs of non-negotiated resources through Content-Location.

> to security concerns Content-Location can never be considered to be a
> substitute for the Request-URI except in cache invalidations even if
> clients MAY use the Content-Location URI in future references to the
> same variant or variant version depending on the server implementation.
> But it's not obvious how to get this down in the correct wording..
> It's also not clear how to handle ETag then a client makes a transition
>>from Request-URI to Content-Location URI for the purpose of authoring a
> negotiated resource or similar.

Good point. That would require a new HTTP feature, right?

BR, Julian
Received on Monday, 7 January 2008 13:24:56 UTC

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