Solution to the CGI message trap

From: Henrik Frystyk Nielsen (
Date: Fri, Aug 07 1998

Message-Id: <>
Date: Fri, 07 Aug 1998 16:27:16 -0400
From: Henrik Frystyk Nielsen <>
Subject: Solution to the CGI message trap

The CGI problem of accepting (returning 200 OK) to arbitrary methods is a
very serious problem and we need a solution urgently in order to be able to
extend HTTP beyond GET, HEAD, PUT, and POST.

Currently, you can't even do a DELETE and know that it works even if you
get 200 OK back which means that neither HTTP/1.1, nor DAV nor Mandatory
can be used reliably.

Here are the possible solutions that I can think of:

a) Add an Ack header field to all responses to mandatory HTTP requests:

	M-GET /foo HTTP/1.1

	200 OK

The problem with this is that it will get cached by HTTP/1.0 caches
regardless of whether we use the cache-control directive or not and hence
may be handed out to another application thinking that it was its extension
declaration that got acked.

b) Introduce a new status code in each status code class, for example 299,
399, 499, and 599 AND introduce a new response header field which indicates
the "normal HTTP/1.1 status code":

	M-GET /foo HTTP/1.1

	299 OK
	Status: 200

The problem with this is that this will confuse existing proxies as they
can not find the end-of-message of this response:

	399 OK
	Status: 304

as they would treat it as 300. The same would be the case with a new main
status code class, say 600.

c) Using a 102 (Extended Response) status response would solve it in a 1.1
world, but it wouldn't work if we have a chain like this

	1.1 client	1.0 proxy	1.1 proxy	1.1 origin server

the origin server will see an HTTP/1.1 proxy and will return a 102 code,
which will not pass the 1.0 proxy and hence the 1.1 client will not know
whether the request was fulfilled.

d) Wrapping the original response in a MIME multipart also doesn't work as
this can make HTTP/1.0 proxies hang as they may not know MIME multipart.


I have therefore limited it to HTTP/1.1 applications as I can't see any
other way around it. That is, a Mandatory compliant server receiving an
extended method must:

1. Identify all mandatory extension declarations (both hop-by-hop and
end-to-end); the server MAY ignore optional declarations without affecting
the result of the transaction;

2. If one or more mandatory extension declarations are present and the
following is not true then respond with a 505 (HTTP Version Not Supported):
o The request MUST NOT come from a HTTP/1.0 client; and
o The request MUST NOT have any HTTP/1.0 clients indicated by the HTTP/1.1
Via header field.

3. If 2) is fulfilled then evaluate and process the extensions identified
in 1) or if the extension declarations do not match the policy for
accessing the resource then respond with a 510 (Not Extended) status-code
(see section 7);

4. If the evaluation in 3) is successful (not resulting in a 510 (Not
Extended) status code) then strip the "M-" prefix from the method name and
process the reminder of the request according to the semantics of the
existing HTTP/1.1 method name as defined in [7].

5. If one or more mandatory extension declarations were present in the
original request and fulfilled by the server then the server MUST reply by
sending a 102 (Extended Response) followed by a normal HTTP/1.1 response.


Henrik Frystyk Nielsen,
World Wide Web Consortium