PUT vs strong ETags

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

PUT vs strong ETags

Julian Reschke

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>




Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Scott Lawrence

On Tue, 2005-11-29 at 11:05 +0100, Julian Reschke wrote:

> 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?

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/



Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Julian Reschke

Scott Lawrence wrote:

> On Tue, 2005-11-29 at 11:05 +0100, Julian Reschke wrote:
>
>> 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?
>
> 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.

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

Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Mark Baker
In reply to this post by Scott Lawrence

On 11/29/05, Scott Lawrence <[hidden email]> wrote:

>
> On Tue, 2005-11-29 at 11:05 +0100, Julian Reschke wrote:
>
> > 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?
>
> 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.

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

Reply | Threaded
Open this post in threaded view
|

RE: PUT vs strong ETags

Henrik Frystyk Nielsen
In reply to this post by Julian Reschke


Having a PUT response include an e-tag associated with the current
entity is necessary in order to avoid the lost update problem (see [1]).
I don't think this is a redefinition of the use of e-tags: section
10.2.2 states that

"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."

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.

Thanks,

Henrik

[1] http://www.w3.org/1999/04/Editing/

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> On Behalf Of Mark Baker
> Sent: Tuesday, November 29, 2005 21:00
> To: Scott Lawrence
> Cc: Julian Reschke; HTTP Working Group
> Subject: Re: PUT vs strong ETags
>
>
> On 11/29/05, Scott Lawrence <[hidden email]> wrote:
> >
> > On Tue, 2005-11-29 at 11:05 +0100, Julian Reschke wrote:
> >
> > > 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?
> >
> > 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.
>
> 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


Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Julian Reschke

Henrik Frystyk Nielsen wrote:
>
> Having a PUT response include an e-tag associated with the current
> entity is necessary in order to avoid the lost update problem (see [1]).
> I don't think this is a redefinition of the use of e-tags: section
> 10.2.2 states that
>
> "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."

Good point, I wasn't aware of that part. But this is for creating
resources (PUT -> 201), what about updating (PUT -> 200)???

> 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.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Mark Baker
In reply to this post by Henrik Frystyk Nielsen

On 11/30/05, Henrik Frystyk Nielsen <[hidden email]> wrote:
>
> Having a PUT response include an e-tag associated with the current
> entity is necessary in order to avoid the lost update problem (see [1]).
> I don't think this is a redefinition of the use of e-tags: section
> 10.2.2 states that
>
> "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."

Good find Henrik.  I still think that's suboptimal from the point of
view of providing a *generic* validator which is independent of
response semantics.  If we were addressing the lost update problem
today, I'd be suggesting minting a new response header which could
carry that ETag.

> 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.

I'm with Julian on that being non-obvious.

Cheers,

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

Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Scott Lawrence
In reply to this post by Julian Reschke

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.

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



Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Julian Reschke

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

Reply | Threaded
Open this post in threaded view
|

Re: PUT vs strong ETags

Julian Reschke

OK,

how about moving the statement about ETAG-on-201 (10.2.2) into thee 2xx
introduction, and make it both more generic (applying to more than 201)
and precise (stating that it's the ETag you'd get upon HEAD)? So...:


Section 10.2.1., para. 0:
OLD:

  10.2.1.  200 OK

NEW:

     The response MAY contain an ETag response header field indicating the
     current value of the entity tag (Section 14.19) for the requested
     variant.  The value SHOULD be the same as the one returned upon a
     subsequent HEAD request addressing the same variant.

  10.2.1.  200 OK

(add new par. at the end of 2xx intro)

Section 10.2.3., para. 0:
OLD:

     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.

  10.2.3.  202 Accepted

NEW:

  10.2.3.  202 Accepted


(remove statement about Etag in response from 201 description).

Feedback appreciated, Julian