- From: Henrik Frystyk Nielsen <frystyk@w3.org>
- Date: Fri, 31 Jul 1998 14:37:59 -0400
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
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. Henrik -- Henrik Frystyk Nielsen, World Wide Web Consortium http://www.w3.org/People/Frystyk
Received on Friday, 31 July 1998 11:39:34 UTC