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 / [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