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. _______________________________________________ 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
