PUT vs strong ETags

Hi,

here's a question the WebDAV working group came across while working on 
RFC2518bis...:

Many servers currently return a ETag response header upon PUT, and, on 
first glance, that's very convenient: one would assume that a client can 
save a subsequent HEAD or GET to find out the Etag of the new or updated 
entity (let's focus on strong entity tags for now).

However, RFC2616 currently says 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.19>) 
about ETag:

"The ETag response-header field provides the current value of the entity 
tag for the requested variant."

As PUT doesn't request any variant, it seems like it's just not defined 
at all.

Now, if a server indeed faithfully stores whatever has been sent with 
PUT, that doesn't seem to be any problem, because it can indeed return 
the ETag upon PUT, having the same value as on a subsequent GET/HEAD 
(overlapping updates ignored).

However, things get more complicated if the server is not a 
general-purpose binary store, but special-cases specific types, such as 
XML (think of an XML database that won't preserve anything not in the 
XML Infoset).

If a server like this would return an ETag upon PUT, would it apply to 
the PUT request body, or the server's internal representation returned 
in a subsequent GET?

- In the former case, the ETag would be different on a subsequent 
GET/HEAD, thus it doesn't seem to make any sense to return it at all.

- In the latter case, a client may be tempted to use the strong ETag in 
subsequent byte-range requests, causing potential file corruption 
(because it doesn't know the binary contents belonging to the ETag after 
all).

All things considered, is it reasonable for RFC2518bis to make return a 
strong ETag upon PUT a SHOULD level requirement (see [1] and [2])?

Best regards, Julian

[1] 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-08.html#rfc.section.8.1.4.p.2>

[2] <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13>

Received on Tuesday, 29 November 2005 10:06:28 UTC