OK, I mentioned this in the last thread, but... I can&#39;t keep up with all this discussion, and I bet you can&#39;t either.<br><br>So, here&#39;s a rough proposal for WSGI and unicode:<br><br>I propose we switch primarily to &quot;native&quot; strings: str on both Python 2 and 3.<br>

<br>Specifically:<br><br>environ keys: native<br>environ CGI values: native<br>wsgi.* (that is text): native<br>response status: native<br>response headers: native<br><br>wsgi.input remains byte-oriented, as does the response app_iter.<br>

<br>I then propose that we eliminate SCRIPT_NAME and PATH_INFO.  Instead we have:<br><br>wsgi.script_name<br>wsgi.path_info (I&#39;m not entirely set on these names)<br><br>These both form the original path.  It is not URL decoded, so it should be ASCII.  (I believe non-ASCII could be rejected by the server, with Bad Request?  A server could also choose to treat it as UTF8 or Latin1 and encode unsafe characters to make it ASCII)  Thus to re-form the URL, you do:<br>

<br>environ[&#39;wsgi.url_scheme&#39;] + &#39;://&#39; + environ[&#39;HTTP_HOST&#39;] + environ[&#39;wsgi.script_name&#39;] + environ[&#39;wsgi.path_info&#39;] + &#39;?&#39; + environ[&#39;QUERY_STRING&#39;]<br><br>All incoming headers will be treated as Latin1.  If an application suspects another encoding, it is up to the application to transcode the header into another encoding.  The transcoded value should not be put into the environ.  In most cases headers should be ASCII, and Latin1 is simply a fallback that allows all bytes to be represented in both Python 2 and 3.<br>

<br>Similarly all outgoing headers will be Latin1.  Thus if you (against good sense) decide to put UTF8 into a cookie, you can do:<br><br>headers.append((&#39;Set-Cookie&#39;, unicode_text.encode(&#39;UTF8&#39;).decode(&#39;latin1&#39;)))<br>

<br>The server will then decode the text as latin1, sending the UTF8 bytes.  This is lame, but non-ASCII in headers is lame.  It would be preferable to do:<br><br>headers.append((&#39;Set-Cookie&#39;, urllib.quote(unicode_text.encode(&#39;UTF8&#39;))))<br>

<br>This sends different text, but is highly preferable.  If you wanted to parse a cookie that was set as UTF8, you&#39;d do:<br><br>parse_cookie(environ[&#39;HTTP_COOKIE&#39;].encode(&#39;latin1&#39;).decode(&#39;utf8&#39;))<br>

<br>Again, it would be better to do;<br><br>parse_cookie(urllib.unquote(environ[&#39;HTTP_COOKIE&#39;]).decode(&#39;utf8&#39;))<br><br>Other variables like environ[&#39;wsgi.url_scheme&#39;], environ[&#39;CONTENT_TYPE&#39;], etc, will be native strings.  A Python 3 hello work app will then look like:<br>

<br>def hello_world(environ):<br>    return (&#39;200 OK&#39;, [(&#39;Content-type&#39;, &#39;text/html; charset=utf8&#39;)], [&#39;Hello World!&#39;.encode(&#39;utf8&#39;)])<br><br>start_response and changes to wsgi.input are incidental to what I&#39;m
proposing here (except that wsgi.input will be bytes); we can decide
about themseparately. <br clear="all">
<br><br><br>Outstanding issues:<br><br>Well, the biggie: is it right to use native strings for the environ values, and response status/headers?  Specifically, tricks like the latin1 transcoding won&#39;t work in Python 2, but will in Python 3.  Is this weird?  Or just something you have to think about when using the two Python versions?<br>

<br>What happens if you give unicode text in the response headers that cannot be encoded as Latin1?<br><br>Should some things specifically be ASCII?  E.g., status.<br><br>Should some things be unicode on Python 2?<br><br>

Is there a common case here that would be inefficient?<br><br><br><br>
-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org" target="_blank">http://blog.ianbicking.org</a>  |  <a href="http://topplabs.org/civichacker" target="_blank">http://topplabs.org/civichacker</a><br>