At 01:28 PM 10/6/2010 +0200, And Clover wrote:
On 10/05/2010 04:23 AM, P.J. Eby wrote:
A preliminary update of the standalone (Python <3.x) version of wsgiref
is now available
Is there any interest in putting fixup code into wsgiref's
CGIHandler? I appreciate this is really ugly, but the CGI-to-WSGI
gateway is the most logical place for this, as otherwise the WSGI
environment created by CGIHandler often doesn't meet the
requirements of the spec.
Trying to fix these problems at an application, framework or
middleware level is impractical because they don't know that the
WSGI environ originally came from CGI. (And they can't re-read the
environ at that point without breaking environ-altering middleware.)
In particular: for Python 2.x running on Win32, read the environment
using ctypes where available, allowing non-ASCII characters to be
read directly instead of irretrievably mangled by the
ANSI-code-page-encoded os.environ interface. Then encode the
extracted Unicode environ to byte strings using ISO-8859-1, except
if the server software is Microsoft/IIS, where the encoding will
probably be UTF-8.
IIS also needs a fix to remove the duplicated SCRIPT_NAME from the
front of PATH_INFO. This is a bit more risky as existing
apps/libraries may already be doing this and might get confused if
someone's already done the fix. Maybe a subclass like IISCGIHandler?
How would these relate to the Python 3.2 release? Can you make 3.x
and 2.x versions?
(I currently consider getting 3.2 out a higher priority, and want
equity between the standalone 0.2 and the bundled version in 3.2.)
_______________________________________________
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
