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

Re: ISSUE: Expect Header Field Problem

From: David W. Morris <dwm@xpasc.com>
Date: Fri, 31 Jul 1998 12:28:51 -0700 (PDT)
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: Scott Lawrence <lawrence@agranat.com>, HTTP Working Group <http-wg@cuckoo.hpl.hp.com>, http-wg@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.980731122204.18009B-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/289

On Fri, 31 Jul 1998, Henrik Frystyk Nielsen wrote:

> 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,
> HEAD and POST.

The problem starts with the fact we've carefully never acknowledged
the CGI interface as being part of HTTP.  What I think is needed is a
MUST requirement that a HTTP server never delegate handling of any
method other then GET, HEAD, or POST to any part of the server which
isn't known to understand / properly handle the unknown method.

I think this requirement is implicit in the spec in any case so it 
isn't a protocol change. It does mean that a conforming HTTP/1.1
server can't handoff an unknown method to a CGI (or *API) program
if there isn't some kind of configuration switch to prevent handing
such requests to an old CGI program. With a server having the ability
to distinguish 'old' methods from new methods and controlling which
application code each will be sent to, the server can't even fix a
failure by disabling the new methods from the old CGI.

Dave Morris
Received on Friday, 31 July 1998 14:40:42 UTC

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