- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Mon, 19 Jun 2006 12:32:53 -0700
- To: Wilfredo Sánchez Vega <wsanchez@apple.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org, Ted Hardie <hardie@qualcomm.com>, CalDAV DevList <ietf-caldav@osafoundation.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Jun 15, 2006, at 9:32 AM, Wilfredo Sánchez Vega wrote: > I agree with Julian. > > As we've mentioned before, Apache returns a weak ETag on PUT, > which turns into a strong ETag sometime later. If clients rely on > being able to use that ETag on a GET later, they won't work with > Apache, and IIRC, Apache is pretty popular. > > The ETag requirements in the draft are what many clients authors > might *like* to be the common case, but it is most certainly not so > today. It's worse than that; many client authors *assumed* that to be the case, and implemented and deployed their clients assuming that if the client receives a strong ETag in response to a PUT, it has no further work to do to synchronize that resource. So the deployed base says that *is* the case today. I don't feel our document makes this situation any worse than the deployed base of clients already does. Lisa > > Additionally, the draft doesn't just say that servers SHOULD > return an ETag in a response when the data has not changed, but > also that they MUST NOT do so if the data did change. It's not > entirely clear that this is the direction things will go, and any > MUST requirements which conflict with whatever we do come up with > later will be a real headache. > > -wsv > > > On Jun 15, 2006, at 4:02 AM, Julian Reschke wrote: > >> I noticed that the ID tracker now has a comment from the authors >> (see <https://datatracker.ietf.org/public/pidtracker.cgi? >> command=view_comment&id=52124>), which I'd like to comment over >> here...: >> >>> Author's response to Last Call comments on ETags >>> 1) Best common practice in WebDAV >>> Currently very few, if any at all, WebDAV servers change the >>> content of resource data during a PUT request. Most WebDAV >>> servers do return an ETag on PUT. Thus clients have come to rely >>> on the presence of the ETag to effectively mean that the resource >>> data was stored unchanged and that the ETag can be used in >>> subsequent GET requests etc. This justifies our statement that >>> servers SHOULD return an ETag in a response when the data has not >>> changed. >> >> I have my doubts that this statement is based on actual testing. >> In particular it seems to me that making claims about "most" >> servers isn't useful here; servers that do rewrite content do >> exist, but they are certainly outnumbered *installation-wise* by >> IIS and Apache/moddav/fs which implement WebDAV as a "dumb" store >> (in that they don't support special semantics on specific content >> types). But that doesn't mean that being incompatible with that >> class of servers (being fully compliant to RFC2616 and RFC2518) is >> acceptable. >> >> That being said, I just tested: >> >> - Microsoft IIS 5.1 (as shipping with XPSP2): No ETag returned >> upon PUT >> >> - Apache/moddav 2.0.55 (WinXPSP2): No ETag returned upon PUT >> >> - Xythos WFS (on www.sharemation.com): ETag returned >> >> - SAP Netweaver KM: ETag returned although content may be rewritten >> >> It seems to me that this shows that the statement above is >> misleading. >> >>> Now we have CalDAV servers where the resource data MAY be >>> changed. Therefore to be compatible with existing client behavior >>> a server MUST NOT send the ETag in a PUT response when the data >>> changes, otherwise clients will misinterpret it. This justifies >>> our 'MUST NOT' statement. >> >> It would be helpful if you could provide an example of a >> *shipping* client that breaks if an ETag is returned upon PUT >> although content was rewritten. >> >>> 2) Restricted behavior >>> The ETag behavior we are talking about is restricted solely to >>> calendar object resources being stored in calendar collections - >>> i.e. it is very specific to CalDAV. This is not 'redefining' HTTP >>> behavior by rather extending it for this one specific application >>> need. >> >> But it's still an HTTP and WebDAV resource. A CalDAV server that >> also happens to be a generic WebDAV server may need to make this a >> special case then. And this may be hard to do should there be >> another HTTP/WebDAV related specification making an incompatible >> requirement. >> >> As a matter of fact, in February the IESG has decided to solve >> that very problem in a separate activity (see draft-whitehead-http- >> etag-00), independently of WebDAV and CalDAV. And, indeed, >> RFC2518bis (the revision of WebDAV) delegates resolution of the >> question to that very spec, instead of coming up with it's own. >> This is what CalDAV should also be doing. >> >>> 3) Future conflicts >>> One of Julian's arguments is that our requirement will "risk >>> making CalDAV incompatible with other specs extending HTTP (or >>> HTTP itself, for that matter)". Since we have been careful to >>> require only behavior that already exists in deployed WebDAV >>> servers, CalDAV adds no further incompatibility. If future work >>> to better define the meaning of ETag on PUT ever happens, it will >>> need to take into account the deployed base, and the subset of >>> CalDAV servers will simply happen to be a consistently behaving >>> subset. We believe that our requirements improve the >>> interoperability of CalDAV, without making the future/potential >>> incompatibility problem any worse than it already is. >> >> See notes above. The behavior required by CalDAV is *not* what >> current servers do. At least not the majority. >> >>> 4) Need/usefulness >>> In addition to the authors' evaluation of the usefulness of this >>> feature for keeping an offline calendar correct, there have been >>> other requests for predictable behavior w.r.t. PUT and ETags and >>> calendar resources. This was one of the first feature requests >>> from client implementors, including Dan Mosedale and Grant Baillie. >> >> I totally agree that clients may be interested in finding out >> whether content was rewritten. The solution to this is to either >> put more energy into draft-whitehead-http-etag-00, or to have a >> CalDAV-specific solution that by design wouldn't interfere with >> what we define in other specs later, as outlined in <http:// >> lists.osafoundation.org/pipermail/ietf-caldav/2006-April/ >> 000787.html>. I'd really like to here why the solution suggested >> back then isn't sufficient for CalDAV. >> >> >> Best regards, Julian >> _______________________________________________ >> Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org >> See http://ietf.webdav.org/caldav/ for more CalDAV resources >> http://lists.osafoundation.org/mailman/listinfo/ietf-caldav > > _______________________________________________ > Ietf-caldav mailing list -- Ietf-caldav@osafoundation.org > See http://ietf.webdav.org/caldav/ for more CalDAV resources > http://lists.osafoundation.org/mailman/listinfo/ietf-caldav
Received on Monday, 19 June 2006 19:33:16 UTC