RE: Summary of ETag related issues in RFC2518bis

Geoff,

I don't follow your reasoning here when you say "the client will 
incorrectly conclude that the text it sent with the PUT is 
what would be retrieved by the GET."  It seems like there are three
cases:

1. The server modifies the value "on the way up", that is, before
returning from the PUT.  (This is typically how a version control system
would expand keywords, as part of the checkin.)  In this case the value
that would eventually be retrieved by GET is known and thus its etag can
be returned, even if that etag is a timestamp.

2. The server returns before modifying the value, but knows that it will
do so.  In this case a synthetic value for the etag can be generated and
returned, as long as the server takes steps to make sure that etag is
returned with the eventual GET and all GETs requested before the
modifications are complete are blocked (e.g., with "server busy").  This
etag can still be a timestamp, by the way, and can even be a timestamp
of the checkin, as long as the server associates that time with the
eventual result (which version control systems also typically do).

3. The server returns before modifying the value, and doesn't know that
a modification will take place.  (For example, the "type" of the file is
later changed so that the file undergoes keyword expansion later.)  In
this case, at the time the file is modified by the server, it should
assign a new etag, because indeed the etag returned at the time of the
PUT should not match what a client would eventually GET.  But before
that later modification is done, the etag is correct.

In no case does a client ever assume that "the text it sent with the PUT
is what would be retrieved by the GET."  That's not what the etag is
for.  The etag is to reassure the client that the value on the server
*has not changed since the PUT completed*.  No guarantees are issued
that the value doesn't change as part of the PUT; that would be a part
of the PUT semantics for that server and are outside the scope of
WebDAV.

    dan



________________________________

	From: w3c-dist-auth-request@w3.org
[mailto:w3c-dist-auth-request@w3.org] On Behalf Of Geoffrey M Clemm
	Sent: Monday, December 19, 2005 19:47
	To: w3c-dist-auth@w3.org
	Subject: Re: Summary of ETag related issues in RFC2518bis
	
	

	Jim: 
	
	What about the point made by an earlier poster, namely that 
	a server is allowed to modify the content stored by a PUT, 
	so that a GET following the PUT might return different content 
	than was PUT (the earlier poster gave the example of a server 
	that expands RCS keywords on PUT). 
	
	In this case (i.e. the server modifies the content stored by 
	the PUT), if server returns the etag that would be returned 
	on a GET, and the client requests a GET with an If-None-Match 
	header with the etag returned by the PUT, the client will 
	incorrectly conclude that the text it sent with the PUT is 
	what would be retrieved by the GET. 
	
	So unless we are going to disallow servers from modifying the 
	content stored from a PUT (note that our server does not do
this, 
	so I am speaking as a neutral party here :-), we pretty much 
	have to have PUT return the entity tag of the content that was 
	PUT, not what would be returned by the GET. 
	
	Then a client that wants to continue modifying a resource to 
	which it has just done a PUT, would need to do a GET with 
	an If-None-Match call following the PUT, to handle servers 
	that do this kind of rewriting on PUT. 
	
	Note that this is just a single GET, not to be confused with 
	the "polling" scenario described in "promotion from weak to 
	strong etag" thread. 
	
	Cheers, 
	Geoff 
	
	
	Jim wrote on 12/19/2005 09:11:02 PM:
	>
	> Julian,
	> 
	> Thanks for making this more clear -- you're right, there is a

	> significant issue here.
	> 
	> > The question here is whether an ETag returned upon PUT is
for the  
	> > entity the client sent (1), or for the entity the server
would send  
	> > upon a subsequent GET (2).
	> >
	> > There are cases where both will not be the same, so this
needs to  
	> > be clarified. In case of (2), a client will need a
subsequent GET  
	> > if it's planning to use the ETag for subsequent GET/Range
requests.
	> >
	> 
	> I think option #2 is the best one here (the Etag returned by
PUT is  
	> the one a subsequent GET would retrieve).

Received on Tuesday, 20 December 2005 05:08:42 UTC