[Python-Dev] PEP 3333: wsgi_string() function (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Fri Jan 7 15🔞44 CET 2011
- Previous message: [Python-Dev] PEP 3333: wsgi_string() function
- Next message: [Python-Dev] PEP 3333: wsgi_string() function
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Jan 7, 2011 at 9:51 PM, Victor Stinner <victor.stinner at haypocalc.com> wrote:
On POSIX, the current code looks like that:
 a) the OS pass a bytes environ to the program  b) Python decodes environ from the locale encoding  c) wsgi.readenviron() encodes environ to the locale encoding to get back the original bytes environ: this step can be skipped if os.environb is available  d) wsgi.readenviron() decodes environ from ISO-8859-1  e) the server/gateway encodes environ to ISO-8859-1  f) the server/gateway decodes environ from the right encoding Hey! Don't you think that there are useless encode/decode steps here? Especially (d)-(e) is useless and introduces a confusion: the environ contains other keys that don't come from os.environ and are already correctly decoded, how do the the server/gateway know that they are already correctly decoded?
Because WSGI is platform neutral. WSGI apps have no idea if they're running on Windows or POSIX. The type used to communicate between the WSGI engine and the WSGI must be either bytes or unicode, and either choice causes problems depending on the underlying OS.
bytes-as-unicode is not a great choice, it is merely the least bad choice of the available options.
Cheers, Nick.
-- Nick Coghlan  |  ncoghlan at gmail.com  |  Brisbane, Australia
- Previous message: [Python-Dev] PEP 3333: wsgi_string() function
- Next message: [Python-Dev] PEP 3333: wsgi_string() function
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]