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

Re: i22: ETags on PUT responses

From: Werner Baumann <werner.baumann@onlinehome.de>
Date: Sat, 05 Jan 2008 22:55:18 +0100
Message-ID: <477FFCC6.8050908@onlinehome.de>
CC: HTTP Working Group <ietf-http-wg@w3.org>

Julian Reschke wrote:
> They can still use it in all kinds of conditional operations. See 
> <http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html> 
> for examples, and keep in mind that just because a resource supports PUT 
> doesn't necessarily mean the server is a replacement for a file server 
> -- the storage may be XML based, for instance.
I would replace "can" with "could". There is an important precondition:
Clients must know whether and how the server changes the body of the 
PUT-request. Without this knowledge the etag is useless.

suggests an additional Entity-Transform-header for this. But there are 
no standardized transformations to transport in this header. The only 
transformation it deals with, is the no-transformation.

Without means to communicate the exact kind of transformation between 
server and client, the only case, where etags on PUT can be useful 
without out-of-band-knowledge, is when the server does no 
transformation, i.e. the next GET will return a body that is 
byte-by-byte identical with the body of the PUT. For WebDAV-clients 
exactly this case is useful and important. And exactly this is 
impossible, if servers send an etag although they changed the content.

When a server changes the body submitted in the PUT-request, it MUST NOT 
send an Etag-header in response, unless it knows that the client is 
aware of this changes and can handle them.

In cases, where server and client know of each other, this is not a 
restriction. Taking examples A.3 and A.4 from 
where a server inserts non-standard WebDAV-properties into a document. 
Whether this single server sends an etag to a handful of specially 
crafted clients, is completely out of the scope of standardization.

If there will some day be means, how servers can inform clients about 
transformations, these can be designed to also transport the etag. But 
this hypothetical case must not block what is useful and possible now.

Received on Saturday, 5 January 2008 21:55:43 UTC

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