[Peter Hunt] > I think CherryPy's WSGI server should go in: it's stable, and the > best-performing WSGI HTTP server out there.
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. 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. 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. Just another €0,02. Regards, Alan. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
