wsgiref 0.2 dev in svn w/PEP 3333 support

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

wsgiref 0.2 dev in svn w/PEP 3333 support

PJ Eby
A preliminary update of the standalone (Python <3.x) version of
wsgiref is now available using "easy_install wsgiref==dev".  Relevant
diffs are here:

   http://svn.eby-sarna.com/?rev=2689&view=rev

This is preliminary work that'll need to be ported to the Python 3
version of wsgiref (note that the standalone version is *not* 2to3
friendly as yet), but I wanted to get the basic implementation done
before porting.

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

and-py
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?

--
And Clover
mailto:[hidden email]
http://www.doxdesk.com/
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

PJ Eby
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
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

and-py
On 10/06/2010 07:21 PM, P.J. Eby wrote:

> How would these relate to the Python 3.2 release? Can you make 3.x and
> 2.x versions?

Yes, I have separate fixup code paths for 2.x and 3.x. 3.x faces the
reverse situation to that previously described, in that os.environ is
accurate on Windows but needs reverse-decoding on POSIX. Currently I use
utf-8 and surrogateescape, but for Python 3.2 presumably os.environb
will be the safer bet.

--
And Clover
mailto:[hidden email]
http://www.doxdesk.com/
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

PJ Eby
At 09:37 PM 10/9/2010 +0200, And Clover wrote:

>On 10/06/2010 07:21 PM, P.J. Eby wrote:
>
>>How would these relate to the Python 3.2 release? Can you make 3.x and
>>2.x versions?
>
>Yes, I have separate fixup code paths for 2.x and 3.x. 3.x faces the
>reverse situation to that previously described, in that os.environ
>is accurate on Windows but needs reverse-decoding on POSIX.
>Currently I use utf-8 and surrogateescape, but for Python 3.2
>presumably os.environb will be the safer bet.

Ok; if you can submit patches against
svn://svn.eby-sarna.com/svnroot/wsgiref (for 2.x) and
http://svn.python.org/projects/python/branches/py3k/Lib/wsgiref (for
3.x), adding an IISCGIHandler and whatever else, I'll review them and apply.

Note, by the way, that just because the environment is unicode on
3.x, doesn't mean it's WSGI-correct: WSGI requires that unicode
environment strings be just bytestrings in disguise.  It's actually
an error if those environment strings contain any character greater than 255!

_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

hidura
If i had a files inside the environ how i can encode the bytes when i going to save them?

On Oct 9, 2010 6:11pm, "P.J. Eby" <[hidden email]> wrote:

> At 09:37 PM 10/9/2010 +0200, And Clover wrote:
>
>
> On 10/06/2010 07:21 PM, P.J. Eby wrote:
>
>
>
>
> How would these relate to the Python 3.2 release? Can you make 3.x and
>
> 2.x versions?
>
>
>
>
> Yes, I have separate fixup code paths for 2.x and 3.x. 3.x faces the reverse situation to that previously described, in that os.environ is accurate on Windows but needs reverse-decoding on POSIX. Currently I use utf-8 and surrogateescape, but for Python 3.2 presumably os.environb will be the safer bet.
>
>
>
>
> Ok; if you can submit patches against svn://svn.eby-sarna.com/svnroot/wsgiref (for 2.x) and http://svn.python.org/projects/python/branches/py3k/Lib/wsgiref (for 3.x), adding an IISCGIHandler and whatever else, I'll review them and apply.
>
>
>
> Note, by the way, that just because the environment is unicode on 3.x, doesn't mean it's WSGI-correct: WSGI requires that unicode environment strings be just bytestrings in disguise.  It's actually an error if those environment strings contain any character greater than 255!
>
>
>
> _______________________________________________
>
> Web-SIG mailing list
>
> [hidden email]
>
> Web SIG: http://www.python.org/sigs/web-sig
>
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/hidura%40gmail.com
>
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

and-py
In reply to this post by PJ Eby
On Sat, 2010-10-09 at 18:11 -0400, P.J. Eby wrote:

> Ok; if you can submit patches...

Done: http://bugs.python.org/issue10155

> Note, by the way, that just because the environment is unicode on
> 3.x, doesn't mean it's WSGI-correct: WSGI requires that unicode
> environment strings be just bytestrings in disguise.

Indeed. On Windows CGI the environment is probably not WSGI-correct. The
only web server I've met that writes bytes-as-code-points
(ISO-8859-1-decoded) to the environ is Apache.

Couple of points on PEP 3333 I noticed whilst adapting this:

> Unicode Issues:
> HTTP does not directly support Unicode, and neither does this
interface. All
> encoding/decoding must be handled by the application; all strings
passed to
> or from the server must be of type str or bytes, never unicode.

This wording probably needs changing now we're going with
bytes-as-code-points unicode environ/status/headers.

> Note also that strings passed to start_response() as a status or as
response headers must
> follow RFC 2616 with respect to encoding. That is, they must either be
ISO-8859-1
> characters, or use RFC 2047 MIME encoding.

They must be ISO-8859-1 period. The mention of RFC2047 in RFC2616 is an
error; HTTPbis work excises this. No browser or server has ever used or
understood RFC2047 encoded-words in HTTP headers; it's questionable
whether RFC2047 can be used in HTTP headers even theoretically. (Since
HTTP headers do not have atoms in the RFC822-family meaning and aren't
defined in terms of RFC822 tokens anyway.)

In the few places you might actually *want* to use encoded-words
(typically quoted-string parameters), RFC2047 explicitly denies that
they may be used (in favour of the even more complicated RFC2231, which
no browser author has even heard of).

Also the Server/Gateway example needs a little more work if it is to be
Python 3 compatible. it would need to use the .buffer properties on
stream IO to get byte IO, and encode to ISO-8859-1. Or just mark the
example as being Python 2-only.

--
And Clover
mailto:[hidden email]
http://www.doxdesk.com/


_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com
Reply | Threaded
Open this post in threaded view
|

Re: wsgiref 0.2 dev in svn w/PEP 3333 support

Ty Sarna-2
On Oct 20, 2010, at 7:48 PM, and-py wrote:

> No browser or server has ever used or
> understood RFC2047 encoded-words in HTTP headers

"All generalizations are wrong" (Mark Twain, I think?)

I work on a codebase that includes a server and multiple client implementations that support and actively use RFC2047 encoded headers. Not that I'm arguing WSGI should support it as a result; the clients and server are mostly only useful for talking to each other. But, for any given weird (mis)feature in a widely implemented spec, you can bet someone somewhere thought it was a good idea to implement it...
_______________________________________________
Web-SIG mailing list
[hidden email]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/lists%40nabble.com