2009/5/5 Graham Dumpleton <graham.dumple...@gmail.com>
>>> Now, if we are going to start using bytes for request headers, there
>>> is the other question of response data.
>>>
>>> The original proposal in amendments was that application should
>>> provide bytes, but that WSGI adapter must accept either bytes or
>>> strings, with strings interpreted as latin-1.
>>>
>>> Is there sense in being more strict in this case?
>>>
>>> In Python 2.X some WSGI adapters only allow Python 2.X strings (ie.,
>>> bytes) and reject unicode strings. Others will convert unicode
>>> strings, but rather than use latin-1, apply the default Python
>>> encoding. Thus, there is no consistency.
>>
>> I think most will assert-reject unicode types and in -O just ignore them
>> and fail in some way. I haven't seen any of those doing a
>> unicode->string conversion by encoding which btw is disallowed by the
>> PEP anyways.
>
> A CGI/WSGI bridge, if no explicit checks are made to disallow stuff
> other than strings, will usually attempt to write to sys.stdout
> whatever you give it. Thus unicode strings can be written and
> presumably default encoding is applied.
>
> >>> sys.stdout.write(u"abcd\n")
> abcd
>
> One can even write buffers.
>
> >>> sys.stdout.write(buffer("abcd\n"))
> abcd
Robert, do you have any comments on the restricting of response
content to bytes and not allow fallback to conversion per latin-1?
I heard that in CherryPy WSGI server you are only allowing bytes. What
is your rational for that at the moment?
Graham
_______________________________________________
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
