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