Re: Etag-on-write, draft -04

Wilfredo Sánchez Vega wrote:
>   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.

I don't think that's what Roy is arguing.

I think what Roy is saying is, if the client receives a strong Etag on
PUT, the client can use it in subsequent conditional and byte-range
requests to confirm that the representation held by the client is
still current, byte for byte.  (It has to be byte for byte otherwise
range requests don't work).  The representation held by the client is
of course what it sent in PUT, because it can't be anything else - it
doesn't have anything else.

That is quite the opposite of what you say he argues, which is "my
editor has no reason to care" that the document was modified by the
server.  On the contrary, Roy's statement on Etag grants the client
the ability to check whether the document was modified.

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

If the editor needs to show the user what would be received by a
subsequent GET, it should do this:

    1. PUT /file
       => Receive Etag in response from PUT

    2. GET /file
       If-None-Match: <etag received in step 1>

The server modifies the file after it's PUT - it replaces $Id$ with
something else.

So the GET will retrieve the new contents - exactly what you asked for.

If the server does not transform the file at all, step 2 will simply
return a "Not Modified" response.

Also exactly what you asked for.

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

And Roy's statement on the meaning Etag gives you 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.

Yes, as I described :)

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

I am surprised at the debate, because it seems quite obvious to me
what a strong Etag is "supposed" to mean as a concept.

That is: if you have received a strong Etag from the server, it means
you may use it for conditional and byte-range GET requests in future,
to confirm the client's stored representation is byte for byte
accurate.

That's what it means for everything else.  I don't see why people want
to give it a different meaning when it's in the response from a PUT.

(And in case anyone's confused, I think that means I agree with Roy).

-- Jamie

Received on Sunday, 3 December 2006 00:25:32 UTC