Re: Logic Bag concerns

> 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:

I strongly disagree with all three points, as already indicated
and explained, and have no intention of changing the syntax as it
currently stands without an explicit directive by the WG as a whole
AND proof that such a scheme can be implemented within the constraints
of the existing HTTP applications.

I am, however, willing to accept explicit restrictions on the set
of precondition expressions allowed in HTTP/1.1 and some ordering
of their preference.  Therefore, if you will only accept preconditions
for cache validation using an opaque value, then I will only accept

    IF: {eq {Content-Version "..."}}

to represent the syntax for cache validation using an opaque value.
If we also wish to allow cache validation if no opaque value is available,
then

    IF: {eq {Content-MD5 "..."}}
and
    IF: {eq {Last-Modified "Thu, 07 Dec 1995 14:08:05 GMT"}}

would also be acceptable (in order, with preference implied).

In order to work at all, preconditions must be a required feature
of HTTP/1.1 or removed entirely -- making them optional is not an option.
Using multiple header fields for preconditions is not acceptable to me
because they make it impossible to extend the conditions without an
exponential increase in feature interaction and a corresponding change
to the standard.  By the time HTTP/1.x is finished, it should be possible
to extend all extensible features without going through this WG.  If not,
then this WG is not working on HTTP.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Friday, 8 December 1995 19:39:41 UTC