Re: PUT vs strong ETags

Scott Lawrence wrote:
> On Wed, 2005-11-30 at 10:12 +0100, Julian Reschke wrote:
>> Henrik Frystyk Nielsen wrote:
> 
>>> The use of the term "requested variant" is consistent with the use in
>>> section 14.19 and elsewhere in the spec. It refers to the resource
>>> identified by the request URI regardless of the method used.
>> Now that's certainly not obvious, and it would be nice if this would 
>> appear somewhere in the errata.
> 
> Before I add anything to the errata, I ask that specific text be posted
> to the WG list and that it gets rough consensus there.

OK.

The WebDAV working group is still chewing on this, so it would be 
extremely good if we got something into the rfc2616 errata document.

First, let's summarize what changes seem to be needed:

1) Explain that when a server returns an ETag as a response header to a 
method such as PUT, it's for the entity the client would get upon a 
subsequent HEAD or GET; *not* for the entity it submitted. This will 
make a difference if the server does rewrite the contents (character 
re-encoding, filtering, keyword expansion, re-serialization from an 
object representation such as XML, iCalendar, ...).

2) This leaves the question open whether it would be a good idea for a 
server to return an ETag upon PUT if it *does* rewrite the content. I 
can see reasons for both. However, if a server does rewrite the content 
and indeed returns an ETag upon PUT, clients must be aware that they 
can't use their copy of what they sent plus the new ETag for GET/Range 
requests.

3) If this applies to PUT, does it also apply to other requests that 
affect the state of the resource, such as POST, PATCH or PROPPATCH? I 
would think so, so recommending to return a new ETag in such as case 
(where the "requested variant" changes) seems to be a good idea.

(Obviously, feedback on these highly appreciated).

Then, let's have a look at the relevant sections from RFC2616:

A) Section 10.2.2 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.2.2>):

"A 201 response MAY contain an ETag response header field indicating the 
current value of the entity tag for the requested variant just created, 
see Section 14.19."

B) Section 14.17 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.19>):

"The ETag response-header field provides the current value of the entity 
tag for the requested variant. The headers used with entity tags are 
described in sections 14.24, 14.26 and 14.44. The entity tag MAY be used 
for comparison with other entities from the same resource (see Section 
13.3.3)."


The main problems I see here is:

in A): this is for a 201 Created, so it doesn't apply to, for instance, 
a 200 Ok when PUTting to an existing resource.

in B): at least to me it is/was completely non-obvious that "requested 
variant" is defined for requests other than GET/HEAD. Assuming we don't 
want to rewrite the spec to use different terminology, what would be the 
best way to explain how this language applies to, for instance, PUT?

Best regards, Julian

Received on Sunday, 15 January 2006 13:47:18 UTC