Re: Solution to the CGI message trap

From: Roy T. Fielding (fielding@kiwi.ics.uci.edu)
Date: Wed, Aug 19 1998


To: Henrik Frystyk Nielsen <frystyk@w3.org>
cc: ietf-http-ext@w3.org
Date: Wed, 19 Aug 1998 11:20:13 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID:  <9808191120.aa26806@paris.ics.uci.edu>
Subject: Re: Solution to the CGI message trap 

>There is a difference between the two statements: "I am capable of doing x"
>and "I am using x". The former is a hint, the latter is a binding
>statement. HTTP Extension Framework works the same was as authentication -
>the client is not guaranteed success based on a hint but on what happens in
>a particular HTTP transaction. Anything can happen in the intermediate time
>frame.

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.  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 HTTP Extension Framework requires two things: a way of indicating
and carrying mandatory extensions within a message, and a way of ensuring
that the recipient understands and will obey the framework.  I have no
problem with the solution to the former, but the latter stuff of adding
an "M-" prefix to method names and twisting the protocol so that it
intentionally breaks across 1.0 hops just plain sucks.  That stuff will
prevent the extension framework from being implemented on servers because
it is too much cruft in comparison to how little benefit is achieved.
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).

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.

....Roy