[Web-SIG] WSGI in standard library

[Ian Bicking]

Alan Kennedy wrote:
>>Anyway, not that it matters, but the security fix was not the only thing
>>in those releases.
> 
> 
> Still, I think my point stands that internet-facing servers in the 
> standard lilbrary are currently the only source of security advisories 
> in python.
> 
> http://www.python.org/security/
> 
> How sure are we that any proposed production WSGI server in the standard 
> library will not become a source of further holes, especially if it 
> tries to cover all the bases of a true production server, i.e. security, 
> flexibility, efficiency, full http1.1 compliance, etc?

Note that the scope of a WSGI server is very very limited.  It is quite 
distinct from an XMLRPC server from that perspective -- an XMLRPC server 
actually *does* something.  A WSGI server does nothing but delegate.

Still, there are certainly some DoS possibilities, but I don't think 
that's something we're handling very gracefully at the moment anyhow. 
Maybe we should, but we're not.  CherryPy's HTTP server does seem to 
have code for that, but then that might just be a cover for the bug in 
the cgi module.  Anyway, even there most DoS issues are out of scope for 
a WSGI server.

I'm not set on "production" quality code, but I think the general 
sentiment against that is entirely premature.  The implementations 
brought up -- CherryPy's 
(http://svn.cherrypy.org/trunk/cherrypy/_cphttpserver.py) and Paste's 
(http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py) and 
wsgiref's 
(http://cvs.eby-sarna.com/wsgiref/src/wsgiref/simple_server.py?rev=1.2&view=markup) 
are all pretty short.  It would be better to discuss the particulars. 
Is there a code path in one or more of these servers which you think is 
unneeded and problematic?

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org