RE: etags in If: headers (was: 54th IETF Meeting Information, and RFC2518 open issues)

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