W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2006

Re: Etag-on-write, 4rd attempt (== IETF draft 03), was: I-D ACTION:draft-reschke-http-etag-on-write-03.txt

From: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>
Date: Sat, 4 Nov 2006 13:33:53 -0800
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DCF14960-C351-4F3D-AEBA-78EE7C9805F1@wsanchez.net>


   I apologize for the absurdly slow response, but here goes.  Overall  
feedback: I think this is excellent.

Section 1.2:

   I'm not sure the "Furthermore" note is interesting.  Of course it  
is possible that one a resource is put onto a server that it's body  
may change again later.  Whether that happens via a PUT request, or  
via PROPPATCH, or even outside of HTTP altogether isn't really all  
that relevant.  What matters is that changed content requires a  
changed ETag, and that's already quite clear in HTTP.

   OK, this becomes clearer when we get to section 5...

Section 1.2:

   The t(e2(e1(c))) = t(e2(t(e1(c)))) explanation is very useful.

   As a general note, I still don't quite understand the widespread  
aversion to weak ETags, and I think that the this editing property  
show why weak ETags *do* work in an authoring environment.  That the  
server might give you a different-but-equivalent representation isn't  
a problem if any "equivalent" version of the document can be edited by  
a client and sent back to the server and produce an "equivalent"  
result in the end.

   I'm rather annoyed that CalDAV was short-sighted here and insisted  
that all calendar resources must have strong ETags when a weak ETag  
could be entirely appropriate, but then I think the entire section  
5.3.4 in CalDAV was hasty and poorly thought out.

Section 4:

   I think it's useful here to say something about weak ETags.  In  
particular, I would expect an entity-transform-keyword of "identity"  
followed by a weak entity-tag to indicate that a semantically  
equivalent entity was stored, not an octet-by-octet copy.  Thus, a  
user agent MUST NOT assume an octet-by-octet entity was stored if a  
weak ETag was assigned.

   I suppose another entity-transform-keyword could indicate semantic  
equivalence, but that's already covered by the nature of the ETag.

Section 4.1:

   What's an example of a situation in which a server would send you a  
stale Entity-Tag header?

Section A.1:

   This example works well to illustrate what you are trying to  
explain, but, for what it's worth, doesn't work well for a Subversion  
client per se.  The reason being that the whole point of the $Revision 
$ keyword is that it shows you want revision of a document you have  
checked out in your working copy.  That is, which is doesn't matter in  
terms of the integrity of the authoring process (what you are  
explaining), it does matter for it's intended usage, which is as an  
informational bit of text maintained by the subversion software in  
your document.

   That said, in this particular case, the client should understand  
this aspect of how the protocol works, and it should be able to modify  
the $Revision$ text in the document itself without having to follow an  
edit with a GET request, assuming that it knows that the ETag == the  
revision number.  That may not work for other keywords, though.

Section A.2:

   This is a particularly notable example if the client did a LOCK  
operation, followed by the PUT and PROPPATCH in the example, in which  
case a client might have more reason to assume that the content hasn't  
been modified since the PUT operation, since no other client could  
have made an edit in the mean time.

Section A.2:

   Note that in Request (3), the title property sent contains spaces  
and newlines which were removed in the new entity body shown.  So even  
in the PROPPATCH example, there is some server-side transformation of  
sent data going on.  Obviously the Entity-Transform header can't help  
us here due to the Multi-Status response, but one might imagine an  
equivalent sort of thing in a new child of the the propstat element.

More on Entity-Transform:

   An Entity-Transform example with a transformed entity might be  
useful.  (I like lots of examples.)  Perhaps an example of PUTing JPEG  
image data where the server stores it as PNG?  It's easy to turn this  
into a rat-hole, I suppose; what if the transform is lossy (PNG- 
 >JPEG), etc.?  Is that worth exploring here, or too zany?

   Perhaps limiting the example to something that's easily  
transformable both ways is best.  iCalendar <-> hCalendar, for  
example.  Of interest here is the change of Content-Type.

   I reckon that you may have lets this out intentionally, to be  
addressed later.  I'm just trying to think of cases where this draft  
might make that sort of operation harder than necessary... not  
thinking of any as yet.

More on weak ETags:

   I think there is room for a weak ETag example here, new style.   
I'll assume for now that my comment about the "identity" entity- 
transform-keyword makes sense:

 >> Request (1)

   PUT /cal.ics HTTP/1.1
   Host: example.com
   Content-type: text/icalendar

   SUMMARY:Lincoln's Birthday

 >> Response (1)

   HTTP/1.1 204 NO_CONTENT
   Content-Type: text/plain
   Entity-Transform: "identity"
   ETag: "W/1"

Because the server stores the iCalendar data in an intermediate  
format, it is possible that the entity changes in a semantically  
equivalent manner between requests, for example:

 >> Request (2)

   GET /test.html HTTP/1.1
   Host: example.com

 >> Response(2)

   HTTP/1.1 200 OK
   Content-Type: text/icalendar
   ETag: "W/1"

   SUMMARY:Lincoln's Birthday

In this case, the iCalendar properties in the event are in a different  
order.  Perhaps the server retrieves these values from separate  
sources and renders them as they arrive; the timing may be different  
in future requests, but the data is semantically equivalent in all  

Regardless, the result is similar to the example in appendix A.2; the  
client can continue editing the cached local copy despite the  
differences that exist in the stored entity on the server.
Received on Saturday, 4 November 2006 21:34:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:40 UTC