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

[Graham Dumpleton]

2009/9/22 Mark Nottingham <mnot at mnot.net>:
> 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?

I thought my blog post explained that reasonably well. Ensure you read
the numbered definitions.

If you can't work it out from the blog, point at the specific thing in
the blog you don't understand and can help. Don't really want to go
explaining it all again.

Graham

> 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/
>
>