Re: Etag-on-write, draft -04

Roy-

> My opinion hasn't changed -- the extension is completely unnecessary,
> RFC 2616 already defines what sending an etag on PUT means,
> and every single relevant case can be handled by a simple  
> clarification.
>
> My proposal was:
>
>     require that ETag in a response to PUT means that the client
>     can use that entity tag in future conditional requests (that
>     includes IMS, If-Match, and Range-based conditional requests).
>
> There is absolutely no reason for the server to send an ETag on a PUT
> response if the server does not intend to support that functionality.
> I am quite sure that none of the server vendors will care about the
> addition of that clarification provided that the requirement is
> properly stated as an interface constraint and not an implementation
> constraint.

   I think Julian's text implies the same thing, but I agree that  
phrasing it terms of "future conditional requests" is probably more  
relevant that phrasing it in terms of "same as a subsequent HEAD  
request".

   Note also that this draft addresses more than PUT.  Since it is  
possible that other methods may alter the ETag, it also clarifies  
that.  I also think the t(e2(e1(c))) = t(e2(t(e1(c)))) is very useful  
for client authors.

> OTOH, the mechanism for how the server "stores" the representation,  
> whether
> or not it is stored byte-for-byte, and how a server might otherwise  
> manage
> to accomplish the feat of handling a conditional request without  
> preserving
> byte-level equality is none of our business and should never appear  
> in an
> IETF specification regarding HTTP.

   I think that in terms of what ETag is meant for, you are totally  
right.

   I also think that there are clients in the world that would like to  
know that if they did a an immediate subsequent GET of the same  
variant, that the data would look different.  Several client authors  
have expressed interest in this information, which is what the Entity- 
Transform is meant to address.

   Example A.1 describes a Subversion server.  Let's say that the  
client isn't the Subversion client, but a text editor, and we have  
auto-versioning enabled on the server.

   My editor saves a document with "$Id$" tags in it.  The server says  
OK and gives me an ETag.

   You are arguing, I think, that my editor has no reason to care that  
the $Id$ tag portion was modified, since subsequent edits will result  
in the same entity on the server, regardless of whether it refreshes  
the modified $Id$ tag in the document, so a clarified ETag should be  
sufficient.

   This is probably true for a lot of editing situations.  In the case  
of normalization of, say, iCalendar data, I think you are right.

   However, in the Subversion example, I think the edit does care,  
because the point of the $Id$ tag is that the user can see what  
version of the document they are looking at when they view the file.   
In this case, knowing that the data was modified will let the editor  
know that a subsequent GET request would be a good idea.  A Subversion  
client wouldn't have to do this, in that it can probably assume that  
it knows what the server changed, and make the same edit itself.  But  
a generic text editor would not.

   I do agree that many client authors are all bent out of shape about  
the data changing when they needn't be, and it's probably best if they  
don't refresh the data unnecessarily, but I do think there are valid  
use cases for having that information.

> My proposal does solve every single case that has been described so  
> far,
> including repeatable server-modifications such as normalization, and
> works with existing clients.

   Is the above use case covered?  I'm not seeing how.

   The ETag this has obviously caused a lot of heartburn.  I'd be  
interested to know whether you think the rest of the draft is good,  
absent the new header.  It's clear that some clarification is needed,  
and I think this is a good start.  No?

	-wsv