Re: Solution to the CGI message trap

From: Henrik Frystyk Nielsen (frystyk@w3.org)
Date: Thu, Aug 20 1998


Message-Id: <3.0.5.32.19980820171828.0394b100@localhost>
Date: Thu, 20 Aug 1998 17:18:28 -0400
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
From: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: ietf-http-ext@w3.org
Subject: Re: Solution to the CGI message trap 

At 11:20 8/19/98 -0700, Roy T. Fielding wrote:

>That's not true in practice.  If you get a promise that something will
>be done, that promise is binding until such time as the promise expires.
>This is no different than the kind of transaction that takes place every
>time you buy something at a supermarket -- you don't have to wait til
>the checkout stand just to find out the item's price.

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.

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

While it is true that if the server dies while sending the response status
line and the client only sees a part of the status line then it doesn't
know for sure what happened. However, this is indeed an extremely unlikely
situation.

>Furthermore, it forces the server core to make capability decisions
>on behalf of its resources, rather than having the resource handler
>itself make that decision (as would happen with OPTIONS).

I would think this depends on how it is implemented. The extension engine
has be able to check a message for extension, call out the extension
modules, get back the results, do an "and" on these results and hand back
the uber result to the core server. Filters would be a straight forward
place to do this.

>Basically, it gives me the willies every time I look at it, and that's
>not a good sign for something I am expected to implement.  I'd be a little
>happier if I knew of a scenario that preferred failure over best-effort
>without also requiring real transaction support, but I don't.

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

Henrik
--
Henrik Frystyk Nielsen,
World Wide Web Consortium
http://www.w3.org/People/Frystyk