Ian Bicking wrote: > 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.
FWIW, CherryPy has gotten a lot of criticism on this front. Our servers are "conditionally compliant" with HTTP/1.1 (specifically relating to Continue), but others prefer to call them broken. Just be aware you'll get the same flak over any candidate for the stdlib. > 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). CP's _cpwsgiserver isn't a party to that special-casing, and handles any method, even fictional ones, equally. However, one thing CP's WSGI server currently does *not* have is the ability for the user to configure SCRIPT_NAME. Christian Wyglendowski is working on a patch for that at the moment, and I think that would have to be built, released, and stable in the field before CP's WSGI server could be considered a candidate for the stdlib. Given how recent *that* feature-request is (only a month or two), I think it's premature for any server to be considered for the stdlib; WSGI needs another year to shake out other, hidden spec-interpretation differences. Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] _______________________________________________ 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
