- 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
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