- From: David W. Morris <dwm@xpasc.com>
- Date: Sat, 1 Aug 1998 22:14:42 -0700 (PDT)
- To: Scott Lawrence <lawrence@agranat.com>
- Cc: HTTP Working Group <http-wg@cuckoo.hpl.hp.com>
On Fri, 31 Jul 1998, Scott Lawrence wrote: > David W. Morris wrote: > > > 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 that crosses the line from being a protocol spec to being a > functional spec for a server, which it should not try to be. There are few > cases where we have put in requirements outside the wire protocol, but they > are mostly governing caching to preserve correctness, or are related to the > security behaviours. OK, then lets stop worrying about the fact that servers invoke brain dead cgi programs. In any case, the requirement I suggested is there to insure correct behavior. I tried to use very general language as to the requirement that base servers take responsibility for what they deliver on the wire. > > >From the point of view of this spec, "the server" is whatever is generating > the response to a request - it encompasses the CGI or *API program, and > those components are as much bound by its requirements as any other part. > Yes, I understand the real world implications of this - and I believe that > those working on a new CGI spec do too. It is easy enough to expect the base server to enforce protocol when invoking API programs. The new CGI spec. is only intended to be an informational RFC. Whether or not a server implements the new CGI specification, it must ensure that what it returns as an HTTP/1.1 response is infact a HTTP/1.1 response. Dave Morris
Received on Saturday, 1 August 1998 22:30:02 UTC