W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

Re: Cache validators

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 26 Feb 1996 20:38:31 +0100 (MET)
Message-Id: <199602261938.TAA28034@wsooti13.win.tue.nl>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy T. Fielding:
>
>> The biggest problem I have with If and logic bags is that you want to
>> _require_ servers to implement them.  The implementation of all
>> proposed conditional modifiers (If-modified-since, If-validator-valid,
>> Variant-Set, Alt-Header) is _optional_, because they are only there as
>> optimization mechanisms.  Server authors could implement none of them
>> and still comply to HTTP/1.1.
>
>That is a reasonable criticism.  However, an extensible mechanism would
>allow implementors to extend the preconditions in order to obtain
>functionality without having to go through the standards process.

True.

[...]
>Finally, not all preconditions are optional; what do we do when the
>implementors need a mandatory precondition?  Do we repeat this whole
>process again?

I do not want to make implementation of If and logic bags a
requirement, just so that people can add mandatory preconditions
without going though the standards process.  The effort required is
too big for the benefit.

[...]
>> Now, the draft says that `the server must abort the request' if the
>> Content-length of the response would be bigger than 123.  The problem
>> is: abort when?  Before or after the send_mail CGI script sends the
>> mail?  As your use of examples in which Unless prevents operations
>> that cost money shows, you seem to require `before'.
>
>Yes, I require "before".  This does not mean that all possible implementations
>will be capable of correctly handling all possible preconditions; the
>assumption is that the client will only use a precondition which is
>*sensible*.  A precondition on content-length is NOT SENSIBLE.

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".

The whole point of a general mechanism like logic bags is that it
would also allow bags that people have not thought of as being
"sensible" before. 

If we add "sensible", we loose generality: people with new
applications for Unless cannot rely on their Unless headers being
processed anymore.

And if we leave "sensible" out, it will be too difficult to implement
completely, so we would get non-conformant servers, and people with
new applications cannot rely on their Unless headers being processed
anymore.

>  The fact
>that you get the possibilty of a nonsensical result is the fault of the
>client and there is nothing the protocol needs to do about that condition.
>
>> My conclusions about implementability: having Unless will only be
>> viable if Unless processing can be done transparently to CGI scripts.
>
>That is wrong.  The CGI implementation, in order to be correct, would
>have to check for preconditions before processing the request.

So I have this HTTP/1.0 httpd which has in its content tree 1000 CGI
scripts written by 100 different people, and before I can upgrade to a
HTTP/1.1 httpd, I have to tell all these people to add logic bag
parsers to their CGI scripts, because else our web site would not
comply to HTTP/1.1?

Impossible.

>How the service is implemented has no effect on the HTTP semantics.

If http semantics require upgrading all CGI scripts, http semantics
will not be implemented.

[...]
>> so you are requiring them to think up and implement `appropriate
>> comparison functions' (including `equals' and `less-than') for 21
>> different headers, if I count correctly.  Exactly how is this supposed
>> to be provably less work than optionally implementing 6 specialized
>> precondition headers?  Not to mention that the number won't be 6, but
>> less.
>
>It is less work for any generic server.  

A generic server has a CGI interface, and CGI scripts can add any
response header they want to the response.  So a generic server would
have to implement all 21 comparison functions.

[...]
>>>So, if people would like a simple precondition syntax that is useful
>>>for all of the currently identified protocol needs, including cache
>>>validation, byte ranges, and content negotiation, then I have the following
>>>suggestion:
>>>
>>>   1) Require Content-ID in HTTP/1.1 responses
>>>
>>>     Content-ID  =  "Content-ID" ":" cid
>>>            cid  =  <a content-id as defined in RFC 1521>
>> 
>> Why require Content-ID to be present in all responses?
>
>Ummmm, I forget.  I guess it would only be necessary for those in which
>the server wanted to support cache validation and byte ranges w/validation.

Yes.

>>>   2) Implement the following precondition syntax:
>>>
>>>     If-ID  =  "If-ID" ":" 1#cid
>>>
>>>      wherein the condition evaluates to true if the response to the
>>>      request would have had a Content-ID equal to one of the ones
>>>      given in the If-ID header field value.  Like the current definition
>>>      of Unless in draft 01, the response to a "false" evaluation
>>>      depends on whether or not Range or IMS is also present.
>> 
>> I think this should be "Unless-ID" (you do a normal GET _unless_ the
>> response will have one of these Content-IDs).
>
>Shucks -- I also want it to mean "do this method if the resource's
>Content-ID is one of these" for methods other than GET.
>I tried both Unless-ID and If-ID, but they always lead to a conflict
>between the name and the intended result.

Maybe this just means that you really want both.  Or something like

   Check-ID  =  "Check-ID" ":" [ "not" ] 1#cid

>  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".)

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

>
>>>That should make a sufficient number of people happy to make the
>>>overhead of doing it worthwhile.  If not, then the only reasonable
>>>solution is to use an IF header field with a generic syntax.
>> 
>> Requiring If and logic bags is not a reasonable solution, they have
>> far to many problems that need to be addressed first.  I'd rather have
>> 6 specialized headers, though it seems that having 2 (Unless-ID and
>> If-Modified-Since for compatibility) is also sufficient.
>
>What I meant is that the only other reasonable solution is a generic syntax.
>It is okay for the required comparisons to be limited to those we have
>already identified to be needed.

With very limited requirements, a general syntax could indeed be
reasonable.  But I think that time is too short for this workgroup to
agree on a syntax with limited requirements for 1.1.

> ...Roy T. Fielding

Koen.
Received on Monday, 26 February 1996 11:42:12 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:46 EDT