W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: ISSUE: Expect Header Field Problem

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Fri, 31 Jul 1998 14:37:59 -0400
Message-Id: <>
To: Scott Lawrence <lawrence@agranat.com>
Cc: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/285
At 17:52 7/31/98 +0000, Scott Lawrence wrote:

>The CGI spec (either the existing 1.1 spec or the new 1.2) just makes the
>method available to the program - if the program doesn't look, it doesn't. 
>Some of the CGI libraries make this easy to do as well - parameters are
>parsed by the library from a GET query string or a POST body transparently,
>for example.  I've tried bouncing TRACE and OPTIONS requests off various
>URLs that were obviously scripts and many respond as though the request were
>a GET. 

You are right - they indeed seem to be largely indifferent except that I
see an added 100 code on PUTs and HEAD responses don't include a body.
>I just took a (very) quick peek at the Apache documentation for adding
>modules, and found a similar API - the method is passed by the server to the
>module, so the core server itself doesn't even appear to have a way to know
>what methods might be handled or not.  Pretty good design if you are
>optimizing for flexibility.

Sure if you have a way of describing what you mean by a new method and that
you have a mechanism for ensuring that it is handled probably. The current
situation is just a recipe for evolutional disaster in HTTP/1.x and it
indeed breaks HTTP/1.1 for any method (including unknown ones) except GET,

Henrik Frystyk Nielsen,
World Wide Web Consortium
Received on Friday, 31 July 1998 11:39:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC