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