Robert Brewer wrote: > 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.
I think the standard library avoids criticism on these kinds of points by underselling itself. Not that people don't complain about SimpleHTTPServer as well... Is what CherryPy does (which I think it just inherits from SimpleHTTPServer) compliant with the HTTP spec? >>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. I think this is a separate issue. The HTTP server should always set SCRIPT_NAME to ''. If it was receiving requests proxied from another server, and got a custom header that somehow indicated some other SCRIPT_NAME, then maybe -- but I don't think that's a necessary feature, nor even a convention that belongs in the standard library at this time. I think the WSGI server discussion lately has been with CherryPy the *framework* acting as a WSGI server, not the CherryPy HTTP server. Other discussions have been around requests coming from non-HTTP-server WSGI sources, where SCRIPT_NAME might not be ''. -- 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
