[Web-SIG] Python 3.0 and WSGI 1.0.

[Graham Dumpleton]

2009/4/17 Robert Brewer <fumanchu at aminus.org>:
> On Thu, 2009-04-16 at 00:12 -0700, Graham Dumpleton wrote:
>> > So, from where I sit, we have:
>> >
>> >  1. Many header values which are ASCII.
>> >  2. A few header values which are ISO-8859-1 plus RFC 2047.
>> >  3. A few header values which are URI's (no specified encoding) or
>> IRI's
>> > (UTF-8).
>> >
>> > I understand the desire to decode ASAP, and I agree with Guido that
>> we
>> > should use a default encoding which the app can override. Looking at
>> the
>> > above, ISO-8859-1 is the best encoding I know of for all three
>> header
>> > cases. ASCII can be used as a valid subset without transcoding;
>> headers
>> > which are ISO-8859-1 are decoded perfectly; URI/IRI headers can be
>> > transcoded by the app if needed, but mangled opaquely by middleware.
>> >
>> > If we make *that* call, then IMO there's no reason not to do the
>> > same to SCRIPT_NAME, PATH_INFO, and QUERY_STRING.
>>
>> I am not sure we ended up with a final answer on all of this, but I
>> don't want to hold up mod_wsgi 3.0, which includes Python 3.0 support,
>> any longer. As such, am implementing things as per:
>>
>>   http://www.wsgi.org/wsgi/Amendments_1.0
>>
>> with exception that will not be attempting to do decoding per RFC
>> 2047. Any CGI variables not related to HTTP headers will also be
>> handled as latin-1, including SCRIPT_NAME, PATH_INFO and QUERY_STRING.
>> This should be equivalent with what wsgiref does in Python 3.X and
>> basically keeps the status quo.
>>
>> If anyone has any last things to say on all of this, please speak up
>> now.
>>
> That sounds fine to me, Graham, and is what I'll be implementing in my
> python3 branch for CherryPy barring any unforeseen impediments.

Are you moving to use of empty string as end of input sentinel for
wsgi.input for case where code does actually read more than
CONTENT_LENGTH?

Graham