[Web-SIG] WSGI in standard library
ianb at colorstudy.com
Mon Feb 6 23:08:26 CET 2006
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 / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG