Re: Logic Bag concerns

> I'm troubled by Logic Bags (3.11), which apparently have been added to
> support the Unless header and byte ranges.  My particular concern is
> how to implement the relational operators, such as "gt".  It seems to
> me that their implementation is header-dependent.  "gt" for
> Last-Modified is different from "gt" for Content-Length and from "gt"
> for "Content-Version".  Now, it's easy to state, on a case by case
> basis, what the correct behavior should be.  But what should a server
> do in the face of unfamiliar headers? 

>From Section 3.11:

   A field-tuple consists of a field-name (assumed to be an HTTP
   header field name, though not constrained to those defined by this
   specification) and the field-value component which is to be
   compared against the resource's field value. The actual method of
   comparison (e.g., byte equivalence, substring matching, numeric
   order, substructure containment, etc.) is defined by the logical
   definition of the operator and the type of field-value allowed for
   that field-name. Server implementors must use an appropriate
   comparison function for each type of field-value given in this
   specification. The default functions for unrecognized fields are
   numeric comparison (for values consisting of 1*DIGIT) and lexical
   comparison (for all others).

   Except for "ne", any comparison to a field not defined by the
   resource evaluates to false.

> Example:
> I get header Foobar: 100.  My bag says {gt {Foobar "AX"}}.  How do I
> compare them?  Lexicographically?  Numerically?  (What base?)

Lexicographically [is that a word?]

I do anticipate that this might cause some problems during the immediate
period of introducing a new header field for which the default comparison
does not apply.  There are ways to solve this [such as a protocol registry],
but I did not want to add too much too soon.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Friday, 1 December 1995 20:27:08 UTC