[Web-SIG] WSGI in standard library

Ian Bicking ianb at colorstudy.com
Mon Feb 6 22:02:07 CET 2006


Bill Janssen wrote:
>>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.
> 
> 
> I strongly disagree with this thinking.  Non-production code shouldn't
> go into the stdlib; instead, Alan's proposed module should go onto
> some pedagogical website somewhere with appropriate tutorial
> documentation.

SimpleHTTPServer has always been pseudo-production.  People use it 
successfully in production environments, but typically in fairly 
constrained environments.  For instance, if you are proxying from 
Apache, Apache isn't going to act crazy with your application.  If your 
application is serving the public, who knows what kind of connections 
you are going to get.  So it works to a degree.

Anyway, I think general rules about this -- choosing simple or complete 
-- is only of limited utility.  There are features that I think can and 
probably should be left out of the standard library.  For instance, 
support for Keep-Alive and Continue.  The server is 100% functional 
without some of these features, it just won't perform as well.  However, 
that doesn't mean we should deliberately choose an implementation that 
takes less into account.

Some things should be supported.  All methods should be supported (and I 
now note that Paste's doesn't do that, but CP's and wsgiref's does, 
though from what I can tell CP's might not support PUT or other methods 
properly, as it special cases POST wrt request bodies).  The server 
should be reasonable easy to use with HTTPS -- maybe not natively, but 
at least providing a mix-in that can be used easily enough.

Anyway, there's some details that should be worked out, and I don't 
think we should slavishly ignore possible enhancements.  But I also 
agree that possibly problematic features (specifically optional HTTP/1.1 
features) can be left out, especially if they can be re-added in 
subclasses (subclasses that would probably have more frequent releases).

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


More information about the Web-SIG mailing list