RE: HTTP If-* headers, etags

   From: Jason Crawford [mailto:ccjason@us.ibm.com]

      So if we want to avoid confusing clients that want to
      interoperate with those implementations, we probably can at most
      say that "PROPPATCH SHOULD NOT modify the etag or modification
      date".

   Sounds good.  So then an ETAG change on a resource indicates to a
   client that the GET response *MIGHT* have changed.  Hopefully we
   can make that a very strong SHOULD so that client checking for the
   "lost update problem" as part of a PUT isn't thrown off.

I'm not sure that one can specify "degrees of SHOULD" (:-),
but certainly one could mention the negative effect that violating
this SHOULD has on caching clients.

   One thing I was concerned about is resources whose GET output changes
   often in hard to predict ways.  For such live resources, the server
   might chose to change the ETAG continuously rather than try to track
   if the GET output has changed.  If this is a red-herring, let me know.

Yes, this is a red-herring (and even if it weren't, it is an HTTP-1.1 issue,
not a WebDAV issue.  Whether or not such a server choses to return
a continuously updated ETAG, or no ETAG at all is just a server choice.

   Upon initial blush, I'd think that this means that "lost-update-checking"
   will always fail.  But I think the answer to that is, you don't do a PUT
   against the live resource.

I don't think we need to (or should) make such a statement.  You could
have a time-of-day resource that is live and continuously updated,
but which allows a PUT to reset the time.  You of course wouldn't
use an If-Match etag with such an update request.

   You should do your PUT/PROPPATCH requests
   against source resources because they don't have this behavior.

That will certainly be the common case, but I don't see that we have
to say anything to that effect.

Cheers,
Geoff

Received on Monday, 29 April 2002 07:42:56 UTC