Re: Solution to the CGI message trap

>That depends on where you get your information from and how much you can
>trust it:
>
>	a) You may have read it in an advertisement paper the previous week
>	b) A friend may have told you about the price
>	c) It may be a sleazy super market with weird looking price tags
>
>If using OPTIONS to test this kind of information, you expect
>
>	1) That the client can trust the information it has about a
>	   resource is valid;
>	2) that you can set individual caching information on each piece
>	   of information, and
>	3) that the information doesn't vary as a result of the requester
>	   and the request.
>
>While this is often true for a super market, I am not sure we can claim
>this to be neither simple to do nor necessarily true in general.

It is guaranteed by law.  A promise transmitted in response to OPTIONS
cannot be disregarded any more than an inline protocol requirement
can be disregarded.  In fact, a promise is far more enforceable, since
the recipient has a record of the agreement.  You just have to spec it
to be nonrepudiable.

>>  Mistakes will
>>occur, but the probability that a server will go from understanding
>>the extension framework to not understanding it in less than half a second
>>is far less than the probability that a resource is deleted halfway
>>through a transaction (and all bets are off in that case).
>
>The latter is detectable in that it wouldn't resolve in a 2xx status code,
>right? The status code is attached to the response as an atomic operation
>only when the server knows that it was OK.

I don't know of any server that does atomic operations.  The status code
is often sent before reading any data from the representation source
(file or whatever).  In any case, the point was that the likelihood of
a server accidentally rebooting and losing the ability to do what it has
just promised to do via OPTIONS (and yet still be able to handle the
request at all) is no more likely than having the server's configuration
change during the middle of any request and losing the extension module
in the process.  It ain't worth worrying about unless you are doing
something safety-critical, in which case you better have full transaction
support for error detection and recovery.

>Real transaction semantics could be required by the client by using
>mandatory together with TIP. Without, it can only be hoped for.

You don't need mandatory to ensure real transaction semantics -- that
would just be a waste of bytes.  Transactions have their own methods,
identifiers and round-trip acknowledgement, so you don't even need OPTIONS.

....Roy

Received on Friday, 21 August 1998 22:59:24 UTC