OK, I'm nearly convinced that an extension mechanism such as
If: <logic-bag>
could be a good thing to have in the HTTP 1.1 spec.
I'm less convinced that we have actually found useful purposes
for it, or that we have a clean semantics for it. The suggestions
made by Sankar Virdhagriswaran (iterators, upgrades, and transactions)
are all (in my opinion) things that are either possible to do without
If:, or things speculative enough that they should probably wait until
some later revision of the spec. (Getting "transactions", in the
formal sense of the term, right almost certainly requires more support
than If: provides).
Meanwhile, Koen Holtman has pointed out that the current specification
has some potential problems (e.g., doing lexicographic comparisons
on dollar-denominated amounts or dates; defining at what point in
the process of serving a request the conditional should be applied).
Koen also pointed out that If: is (in some applications) "basically a
bandwidth-saving device" (although if it could be used to implement
transactions, that would be different). I think this observation
might lead us to a clearer set of design principles:
Since If: is being proposed primarily as an extension mechanism,
and we don't quite know how to make it work yet, how about making
it optional? That is,
(1) servers need not support If:
(2) If: should only be used (in HTTP 1.1) as a technique
for optimizing performance, and never for ensuring
correctness.
(3) Features that apply to all or many requests
should be implemented as specific headers, rather than
If: extensions, since this allows more efficient
implementation and probably more efficient on-the-wire
encodings.
To my mind, this means that cache validation and byte ranges
ought to be standalone headers, and not implemented using If:
We know we need them, and they are simple enough to implement
without If:
-Jeff