If-ID and Unless-ID Preconditions

Koen writes:
> Eek!  You can't just say "servers must be capable of handling any
> sensible Unless header" in a protocol definition.  Not without giving
> a complete definition of "sensible Unless header".

No problemo:

   A sensible precondition for a given request method and Request-URI
   is one that can be checked prior to the method being applied to that
   Request-URI.  Any non-sensible precondition may be ignored.

Regarding the other option...

> Maybe this just means that you really want both.  Or something like
> 
>    Check-ID  =  "Check-ID" ":" [ "not" ] 1#cid

Nope -- that runs into problems if there are multiple Check-ID fields.

>>  How about something neutral
>>like Check-ID?
>>
>>   Check-ID  =  "Check-ID" ":" 1#cid
>>
>>Let's see what the semantics are for a request containing Check-ID:
>>
>>                        ID is in    ID not in
>>                        Check-ID    Check-ID (or IMS true)
>>                        ---------   ---------
>>    GET                    200         412
> 
> I believe you mean
> 
>      GET                    412         200
> 
> (For those of you not looking at a copy of the draft spec: 412 would
> mean "Check true", 304 is "Not modified".)

Sorry, my fault, I should have said that 412 means "Precondition False".
That makes the error code more appropriate (and less confusing) than
the old "Unless True".

>>    GET + IMS              304         200
> 
> I would make this
>                          
>      GET + IMS              412         200 or 304
> 
> 
>>    GET + Range            206         412
>>    GET + IMS + Range      206         200
>>    other methods       as normal      412
>>
>>That would take care of Ari's desire for a "give me an error instead"
>>type of precondition for Range as well.
> 
> Hm, taking care of it this way would be a bit of a hack, though.

Yes, I prefer an option in the Range header.  However, the above is no more
of a hack than what is currently in the Range Retrieval spec.  The problem
is that what is desired is two different results if the precondition fails,
and thus using Unless-ID vs If-ID (or If-Invalid vs If-Valid, as is in
the current draft) is no help because it just changes the precondition.

============================================================
In summary, the proposal now looks like:

      200 == OK
      206 == Partial Content
      304 == Use Local Copy [includes the Content-ID of the copy chosen]
      412 == Precondition False

   GET unless we would be given one of the variants already cached:

     Request:   GET + Unless-ID
     Response:  304 if Content-ID  is in Unless-ID
                200 if Content-ID not in Unless-ID

   Cache validation:

     Request:   GET + IMS + Unless-ID
     Response:  304 if Content-ID  is in Unless-ID
                200 if Content-ID not in Unless-ID

   Partial GET (w/OK response if changed):

     Request:   GET + Range + If-ID
     Response:  206 if Content-ID  is in If-ID
                200 if Content-ID not in If-ID

   Partial GET (w/bad response if changed):

     Request:   GET + Range + If-ID + [some indicator in Range]
     Response:  206 if Content-ID  is in If-ID
                412 if Content-ID not in If-ID

   Precondition for all other methods:

     Request:   method + If-ID
     Response:  2xx if Content-ID  is in If-ID
                412 if Content-ID not in If-ID

     Request:   method + Unless-ID
     Response:  412 if Content-ID  is in Unless-ID
                2xx if Content-ID not in Unless-ID


I think that is a reasonable and simple design.

 ...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 Thursday, 29 February 1996 03:02:05 UTC