[Web-SIG] WSGI in standard library

[Guido van Rossum]

> [Peter Hunt]
> > I think CherryPy's WSGI server should go in: it's stable, and the
> > best-performing WSGI HTTP server out there.

[Alan Kennedy]
> I disagree.
>
> I think that if a WSGI server is to go into the standard library, it
> should be the most basic one possible, e.g. one that builds on the
> *HttpServer.py hierarchy already there, and one that makes it as easy as
> possible for coders to understand how WSGI works.

Right.

> HTTP servers can be complex beasts. Security is a major consideration,
> robustness and stability being next. Performance is also a major
> concern, with flexibility and ease-of-use being important as well.
>
> That's too many concerns to balance against each other for a python
> library module.

Exactly.

> Instead, I think the right approach is to continue with the existing
> approach: put the most basic possible WSGI server in the standard
> library, for educational purposes only, and a warning that it shouldn't
> really be used for production purposes.
>
> The following quote is from the docstring of the CGIHTTPServer module
>
> """
> In all cases, the implementation is intentionally naive -- all
> requests are executed sychronously.
>
> SECURITY WARNING: DON'T USE THIS CODE UNLESS YOU ARE INSIDE A FIREWALL
> -- it may execute arbitrary Python code or external programs.
> """
>
> And that's a good thing. If I really want to use python CGI, then I
> should find a robust HTTP server which supports it, e.g. Apache.
>
> The same reasoning should apply to WSGI, IMHO.

Except for the security warning, probably -- that only applies to
CGIHttpServer.py, not to BasicHTTPServer.py. (It does in a sense apply
to SimpleHTTPServer.py since that serves up the current directory.)

Thanks for correctly channeling the sentiment behind the standard
library server hierarchy!

--
--Guido van Rossum (home page: http://www.python.org/~guido/)