Subject: PUT vs strong ETags

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Nov 2005 11:05:07 +0100

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>

---

From: Scott Lawrence <[email-masked]>
Date: Tue, 29 Nov 2005 15:43:06 -0500

> the PUT request body, or the server's internal representation returned 

I think that the simple rule is that when responding to a PUT, if the
server returns an Etag, then it should be the same value that would have
been returned in a GET of the resource that immediately followed the
PUT.

-- 
Scott Lawrence
http://skrb.org/scott/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Nov 2005 22:19:41 +0100

> been returned in a GET of the resource that immediately followed the

Somebody else pointed out in the meantime that the same question applies 
to Last-Modified.

Anyway, if this is what everybody agrees upon, this IMHO should be put 
into the RFC2616 errata.

Also, it means that an ETag obtained from a PUT response can not be used 
as validator in byte-range operations, right? That may come as a 
surprise to some ;-)

Best regards, Julian

---

From: Mark Baker <[email-masked]>
Date: Tue, 29 Nov 2005 23:59:30 -0500

> been returned in a GET of the resource that immediately followed the

My understanding is that an ETag is associated only with the provided
representation (and the resource whose state it represents); in this
case the one in the PUT response.  What's suggested above then, would
seem to be a redefinition of ETag semantics.  But perhaps it's already
common enough on PUT responses to warrant standardizing despite the
drawbacks, I don't know.

I do agree that the "requested variant" language is problematic though.

Mark.
--
Mark Baker.  Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Coactus; Web-inspired integration strategies   http://www.coactus.com