On Tue, Aug 11, 2009 at 11:19 PM, Robert Brewer <span dir="ltr">&lt;<a href="mailto:fumanchu@aminus.org">fumanchu@aminus.org</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">








<div>


<p><font size="2"></font></p><font size="2"><div class="im">&gt; 5. When running under Python 3, servers MUST provide CGI HTTP and</div><div class="im">
&gt; server variables as strings. Where such values are sourced from a byte<br>
&gt; string, be that a Python byte string or C string, they should be<br>
&gt; converted as &#39;UTF-8&#39;. If a specific web server infrastructure is able<br>
&gt; to support different encodings, then the WSGI adapter MAY provide a<br>
&gt; way for a user of the WSGI adapter to customise on a global basis, or<br>
&gt; on a per value basis what encoding is used, but this is entirely<br>
&gt; optional. Note that there is no requirement to deal with RFC 2047.<br>
<br></div>
We&#39;re passing unicode for almost everything.<br>
<br>
REQUEST_METHOD and wsgi.url_scheme are parsed from the Request-Line, and must be ascii-decodable. So are SERVER_PROTOCOL and our custom ACTUAL_SERVER_PROTOCOL entries.<br>
<br>
The original bytes of the Request-URI are stored in REQUEST_URI. However, PATH_INFO and QUERY_STRING are parsed from it, and decoded via a configurable charset, defaulting to UTF-8. If the path cannot be decoded with that charset, ISO-8859-1 is tried. Whichever is successful is stored at environ[&#39;REQUEST_URI_ENCODING&#39;] so middleware and apps can transcode if needed. Our origin server always sets SCRIPT_NAME to &#39;&#39;, but if we populated it, we would make it decoded by the same charset.<br>


</font></div></blockquote><div><br></div><div>My understanding is that PATH_INFO *should* be UTF-8 regardless of what encoding a page might be in.  At least that&#39;s what I got when testing Firefox.  It might not be valid UTF-8 if it was manually constructed, but then there&#39;s little reason to think it is valid anything; only the bytes or REQUEST_URI are likely to be an accurate representation.  (Frankly I wish PATH_INFO was not url-decoded, which would remove this issue entirely -- REQUEST_URI, or any url-encoded value, should really be ASCII, and I don&#39;t know of reasonable cases where this wouldn&#39;t be true.)</div>

<div><br></div><div>I suppose ISO-8859-1 is a reasonable fallback in this case, as it can be used to kind of reconstruct the original request path (the surrogateescape or whatever it is called would serve the same purpose, but is only available in Python 3).</div>

<div><br></div></div>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a>  |  <a href="http://topplabs.org/civichacker">http://topplabs.org/civichacker</a><br>