Re: Solution to the CGI message trap

From: Henrik Frystyk Nielsen (
Date: Tue, Aug 11 1998

Message-Id: <>
Date: Tue, 11 Aug 1998 20:11:14 -0400
To: Scott Lawrence <>, Jeffrey Mogul <>
From: Henrik Frystyk Nielsen <>
Cc: "David W. Morris" <>,
Subject: Re: Solution to the CGI message trap

At 11:59 8/11/98 +0000, Scott Lawrence wrote:
>Jeffrey Mogul wrote:
>>     This would be exactly my point ... if a new method is sent to a
>>     server which doesn't support the application which uses the new
>>     method, so what?  Brain dead client application gets what it
>>     deserves ... a brain dead response.
>> Right.  But the problem remains, how is the client supposed to know
>> whether or not the server supports the application in question? 
>Why doesn't OPTIONS fit the bill here?  If I send OPTIONS and get back
>something that looks like a GET response, I can pretty much figure out that
>I've hit something brain dead.

This is the same discussion we had a long time ago:

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

The current problem with CGIs is not a question of exchanging information
about capabilities or features, it is a question of the client not being
able to trust that 200 OK means that the server understood the request and
handled the request according to the semantics specified in HTTP.

If we don't require that HTTP conforming applications behave according to
the spec wrt 200 OK then HTTP is not automatable. HTTP MUST be automatable
- whether it is automated or not is not doesn't make any difference from a
design perspective.

Don't get me wrong, OPTIONS is nice to have, but it doesn't solve the
problem that the new HTTP extension framework draft does. The draft that I
just submitted [1] uses the 102 (Extended) intermediate response and not
the ACK/nounce. Both mechanisms have the basic functionality needed:

	* Provides "HTTP transaction" semantics (1 RTT)
	* Provides once and for all a mechanism for the client
	  to make sure that the server understood the request
	  and that it can trust the response code

but in addition, the 102 (Extended) code has the following advantages:

	* It is guaranteed to go away immediately and never be
	  reused (no privacy problems)
	* It can not tempt people to use it as a cookie alternative
	* It doesn't affect caching at all

I believe these factors are crucial and besides, I am not really interested
in experimenting with extending HTTP/1.0 applications.


Henrik Frystyk Nielsen,
World Wide Web Consortium