- From: Clemm, Geoff <gclemm@rational.com>
- Date: Thu, 25 Apr 2002 08:46:17 -0400
- To: "Webdav WG (E-mail)" <w3c-dist-auth@w3c.org>
I think a key point is the one Greg made at the end of this message, namely that this use case can be achieved without allowing etags in the If header. In particular, you just try the PUT with the LOCK request, and if that fails because you no longer have the lock, you retry the PUT with the appropriate etag in an If-Match header. I think it is very reasonable to require an extra round trip in an exceptional case like this (i.e. losing your lock). So until a use case is identified that cannot be easily handled by other machinery, I suggest we limit the If header to just lock tokens. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Thursday, April 25, 2002 2:40 AM To: Webdav WG (E-mail) Subject: etags in If: headers (was: 54th IETF Meeting Information, and RFC2518 open issues) On Mon, Apr 22, 2002 at 06:53:34PM +0200, Stefan Eissing wrote: > Am Montag den, 22. April 2002, um 18:36, schrieb Lisa Dusseault: >... > If headers with ETags do not add any value to the protocol. For > GET rfc2616 already defines If-Match and friends. Since the ETag > only captures content changes (property changes have undefined > effect on ETags), IF headers for ETag lack a use case. An etag in an If: header can be used to assert that a file has been unchanged since you last fetched it. Specifically, that you still have the locktoken *or* (you lost it and) it is unchanged. This is to cover the case where lock a file, fetch it, and then attempt to PUT the file back. The PUT should succeed if you have the locktoken *or* if you lost your lock but the etag matches what you GET'd (thus: nobody else changed it). Arguably, the semantic could be manufactured with other combinations, but I'd suggest that is your use case. Cheers, -g -- Greg Stein, http://www.lyra.org/
Received on Thursday, 25 April 2002 09:10:10 UTC