[Web-SIG] WSGI type tolerance

[Phillip J. Eby]

At 12:33 AM 9/8/2006 -0700, Robert Brewer wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6D319.11101680"
>
>See 
><http://www.cherrypy.org/ticket/561>http://www.cherrypy.org/ticket/561. 
>Apparently, "several WSGI apps" return an int for the Content-Length 
>header. PEP 333 leaves just enough unsaid that someone might determine 
>that's OK. But wsgiref and paste.lint certainly seem to think header 
>values must be strings. Can we tighten up the language in the PEP on this 
>point (or just agree on an interpretation here, so it's documented)?

Those apps or servers are definitely broken; CGI environment variables are 
always strings.  I would urge you to have CherryPy reject servers or 
middleware providing integer content-length as broken, preferably with an 
error that indicates the application is not WSGI-compliant.

I'll change the phrasing of this:

"""The environ dictionary is required to contain these CGI environment 
variables, as defined by the Common Gateway Interface specification."""

to:

"""The environ dictionary is required to contain these CGI environment 
strings, as defined by the Common Gateway Interface specification."""

So that there is absolutely no room for ambiguity, although the CGI 
specification quite clearly calls for strings.  In the meantime, feel free 
to cite this message and point folks in the direction of wsgiref.validate 
(which is actually paste.lint under a different name).  It's also 
recommended that middleware authors test their middleware by using 
wsgiref.validate on *both* the server and application sides, not just one 
or the other.