[Web-SIG] WSGI in standard library

[Ian Bicking]

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