[Web-SIG] WSGI in standard library

[Robert Brewer]

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
fumanchu at amor.org