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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ 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