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

[Paul Boddie]

Gregory (Grisha) Trubetskoy wrote:
>
> 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).

I would have thought that this kind of interface would have been more
suitable between the environment and the container, or possibly between
components within the container.

> 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 I can imagine that for many applications in many of the current
frameworks, they would need some kind of "insulating wrapper" to comply with
this interface. Certainly, I don't recall Webware, mod_python, Twisted or
Zope applications sending headers to the same output stream as the data (or
even using an output stream for the headers at all).

[...]

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

Agreed. I think we also need to consider where this interface "surfaces" in
the application or framework; ie. where you would expect to find it, and
what might sit on top. As I noted above, right now, many applications would
need a few framework calls between the invocation of the runCGI function and
an actual entry point into the application itself.

This pre-PEP seems to serve an important purpose: it attempts to make a
certain part of the Web request handling "stack" explicit. I'd certainly be
interested in trying to make other parts of that "stack" more obvious, too.
For example, it would be nice to consider the resolution of requests
according to information contained within them, and the dispatching of such
requests to resources. Right now, each framework seems to have its own
ideology which states that requests using particular paths must get resolved
in a particular way - it would be great if an API appeared that let
developers rewire frameworks without resorting to external hacks to get the
desired behaviour.

Paul