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

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 25 Apr 2002 08:46:17 -0400

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:[email-masked]]
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/

---

From: "Jim Whitehead" <[email-masked]>
Date: Thu, 25 Apr 2002 10:53:51 -0700

The original rationale for including entity tags in the If header was to
make the If header a general purpose mechanism for evaluating method
preconditions (specifically, for evaluating preconditions concerning whether
the resource's state still matched the state expected by the client, where
the client's current understanding of the state is expressed using a state
token, like an Etag or a LockToken). We were reacting against the closed
design of the existing If-[None-]Match headers, which didn't allow expansion
to include other state tokens.

Our hope was that the If header would eventually replace the existing
If-[None-]Match mechanism.

One scenario that you can accomplish with the If header, and that you cannot
accomplish with other mechanisms, is to perform an operation like a MOVE on
a collection hierarchy, where the MOVE can only succeed if the client has
the right lock token and all of the resources have the Etag expected by the
client (i.e., they haven't been modified, which may be the case with shared
locks).

If the main concern about the feature is interoperability, then let's make
testing of this feature an issue at the next interoperability event, and add
a few tests concerning it to the Litmus test suite.

- Jim

---

From: Yves Lafon <[email-masked]>
Date: Fri, 26 Apr 2002 04:22:30 +0200 (MET DST)

> other machinery, I suggest we limit the If header to just lock tokens.

Well, using also ETag verification allows consistency check. If you still
have your lock and the ETag has changed, then it's because something nasty
happened on the server side (as the ETag represents more or less a version
tag of the resource).
As it won't cost anything, I don't understand why you want to remove a
consistency check.

-- 
Yves Lafon - W3C

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 26 Apr 2002 09:15:32 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Yves Lafon
> Sent: Friday, April 26, 2002 4:23 AM
> To: Clemm, Geoff
> Cc: Webdav WG (E-mail)
> Subject: RE: etags in If: headers (was: 54th IETF Meeting Information,
> and RFC2518 open issues)
>
>

That would be an internal server error -- I don't think the *protocol* needs
to allow discovery of problem like these...

> As it won't cost anything, I don't understand why you want to remove a

Well, that's exactly the point: every feature that's hard to implement, of
questionable use *does* cost (in implementation/debugging time).

So the feature should stay if

- it gives us something that can't be easily done otherwise

- we have proven interoperability.