[Web-SIG] Pre-PEP: Python Web Container Interface v1.0

[Gregory (Grisha) Trubetskoy]

I must say this is very well written, and seeing such level of
thoroughness on this list makes me very hopeful, because it produces a
substantive discussion. My hat's off to Phillip for making the effort to
write this.

Having said that, I'm -1 on this PEP. I think it does a very good job of
stating the problem (and this in itself is immensely valuable), but I do
not agree with the solution. I think it trades efficiency for simplicity,
and to paraphrase Franklin, if you give up one for the other you will get
neither :-)

The approach this spec takes is modeled after CGI, which was designed with
shell scripts in mind and condenses things down to the UNIX primitives of
stdin, stdout, stderr, environ (and cwd).

On the surface this appears fine, but consider setting an HTTP header.
Headers do not fit into the above-mentioned primitives, so CGI requires
the application to send them to stdout. Writing headers to stdout is much
more cumbersome than passing them in a mapping object of some sort. And
most web server's CGI implementations do not pass the header portion of
stdout straight to the client. They actually parse those headers,
optionally alter them and adjust their own behavior based on the header
information, then add the resulting data to the server header structure
(e.g. headers_out table in case of Apache). This is inefficient, and ugly.
And it is a direct consequence of the way CGI is specified.

It is understandable why CGI does it, given that CGI was meant for running
executables in a separate process on UNIX to serve a request. But there is
no reason why such limitations should be carried over to environments that
do not have the constraints of CGI. Especially considering that the whole
idea of running an executable to serve an HTTP request looks pretty weird
as a way to develop web applications these days.

Whatever spec we come up with, IMO should deal in terms of the HTTP
protocol request, headers, body, etc. Trying to narrow it down to input,
output and environment is fitting a square peg into a round hole.

Three other notes:

1. On the threading point - aside from thread-safety there is another big
issue, it's the shared memory space. Some frameworks assume that they are
running in one process and take it for granted that making something
global will make it available to all other requests, which obviously isn't
going to work on per-process servers.

2. If we're going to refer to a CGI specification, then we should rely on
the RFC draft at http://cgi-spec.golux.com/. The stuff at NCSA's hoohoo
page is more of a joke than a spec.

3. Mod_python *can* be threaded on apache 1.3, because 1.3 is threaded on
Windows. Considering that Apache, IIS and iPlanet (or whatever it's called
now) account for vast majority of the web servers out there, there are
likely more threaded servers than not threaded, so I wouldn't through out
thread-safety as a non-consideration.

Grisha