Re: [Ietf-caldav] Last Call comment on Etag requirements in draft-dusseault-caldav-12

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  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.

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@xxxxxxxxxxxxxxxxx
See http://ietf.webdav.org/caldav/ for more CalDAV resources
http://lists.osafoundation.org/mailman/listinfo/ietf-caldav


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]