RE: etags in If: headers

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

Received on Thursday, 25 April 2002 13:54:20 UTC