[Web-SIG] Request for Comments on upcoming WSGI Changes

[Mark Nottingham]

So, what advice do you propose about decoding bytes into strings for  
the request-URI / method / request headers, and vice versa for  
response headers and status code/phrase? Do you assume ASCII, Latin-1,  
or UTF-8? How are errors handled?

Are bodies still treated "as binary byte sequences", as per PEP 333?

Cheers,

On 22/09/2009, at 4:07 PM, Graham Dumpleton wrote:

> 2009/9/22 Mark Nottingham <mnot at mnot.net>:
>> OK, that's quite exhaustive.
>>
>> For the benefit of those of us jumping in, could you summarise your  
>> proposal
>> in something like the following manner:
>>
>> 1. How the request method is made available to WSGI applications
>> 2. How the request-uri is made available to WSGI applications -- in
>> particular, whether any decoding of punycode and/or %-escapes happens
>> 3. How request headers are made available to WSGI apps
>> 4. How the request body is made available to to WSGI apps
>> 5. Likewise for how apps should expose the response status message,  
>> headers
>> and body to WSGI implementations.
>
> Same as the WSGI PEP.
>
>  http://www.python.org/dev/peps/pep-0333/
>
> Nothing has changed in that respect.
>
> Graham
>
>> Cheers,
>>
>>
>> On 22/09/2009, at 12:26 PM, Graham Dumpleton wrote:
>>
>>> 2009/9/22 Mark Nottingham <mnot at mnot.net>:
>>>>
>>>> Reference?
>>>
>>> See:
>>>
>>>
>>>  http://blog.dscpl.com.au/2009/09/roadmap-for-python-wsgi-specification.html
>>>
>>> Anyone else jumping in on this conversation with their own opinions
>>> and who has not read it, should perhaps at least read that. Also  
>>> read
>>> some of the earlier posts in the numerous discussions this spawned  
>>> at:
>>>
>>>  http://groups.google.com/group/python-web-sig?lnk=
>>>
>>> as the current thinking isn't exactly what I blogged about and has
>>> shifted a bit as the discussion has progressed.
>>>
>>> Graham
>>>
>>>> On 22/09/2009, at 12:07 PM, Graham Dumpleton wrote:
>>>>
>>>>> 2009/9/22 Mark Nottingham <mnot at mnot.net>:
>>>>>>
>>>>>> Most things is not the Web. How will you handle serving images  
>>>>>> through
>>>>>> WSGI?
>>>>>> Compressed content?  PDFs?
>>>>>
>>>>> You are perhaps misunderstanding something. A WSGI application  
>>>>> still
>>>>> should return bytes.
>>>>>
>>>>> The whole concept of any sort of fallback to allow unicode data  
>>>>> to be
>>>>> returned for response content was purely so the canonical hello  
>>>>> world
>>>>> application as per Python 2.X could still be used on Python 3.X.
>>>>>
>>>>> So, we aren't saying that the only thing WSGI applications can  
>>>>> return
>>>>> is unicode strings for response content.
>>>>>
>>>>> Have you read my original blog post that triggered all this  
>>>>> discussion
>>>>> this time around?
>>>>>
>>>>> Graham
>>>>>
>>>>>> On 22/09/2009, at 1:30 AM, René Dudfield wrote:
>>>>>>
>>>>>>> here is a summary:
>>>>>>>  Apart from python3 compatibility(which should be good enough
>>>>>>> reason), utf-8 is what's used in http a lot these days.  Most  
>>>>>>> things
>>>>>>> layered on top of wsgi are using utf-8 (django etc), and lots  
>>>>>>> of web
>>>>>>> clients are using utf-8 (firefox etc).
>>>>>>>
>>>>>>> Why not move to unicode?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mark Nottingham     http://www.mnot.net/
>>>>>>
>>>>>> _______________________________________________
>>>>>> Web-SIG mailing list
>>>>>> Web-SIG at python.org
>>>>>> Web SIG: http://www.python.org/sigs/web-sig
>>>>>> Unsubscribe:
>>>>>>
>>>>>>
>>>>>> http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com
>>>>>>
>>>>
>>>>
>>>> --
>>>> Mark Nottingham     http://www.mnot.net/
>>>>
>>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>


--
Mark Nottingham     http://www.mnot.net/