On Fri, Jul 16, 2010 at 9:43 PM, Chris McDonough <span dir="ltr">&lt;<a href="mailto:chrism@plope.com">chrism@plope.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div><div></div><div class="h5">&gt; Nah, not nearly that hard:<br>
&gt;<br>
&gt; path_info =<br>
&gt; urllib.parse.unquote_to_bytes(environ[&#39;wsgi.raw_path_info&#39;]).decode(&#39;UTF-8&#39;)<br>
&gt;<br>
&gt; I don&#39;t see the problem?  If you want to distinguish %2f from /, then<br>
&gt; you&#39;ll do it slightly differently, like:<br>
&gt;<br>
&gt; path_parts = [<br>
&gt;     urllib.parse.unquote_to_bytes(p).decode(&#39;UTF-8&#39;)<br>
&gt;     for p in environ[&#39;wsgi.raw_path_info&#39;].split(&#39;/&#39;)]<br>
&gt;<br>
&gt; This second recipe is impossible to do currently with WSGI.<br>
&gt;<br>
&gt; So... before jumping to conclusions, what&#39;s the hard part with using<br>
&gt; text?<br>
<br>
</div></div>It&#39;s extremely hard to swallow Python 3&#39;s current disregard for the<br>
primacy of bytes at I/O boundaries.  I&#39;m trying, but I can&#39;t help but<br>
feel that the existence of an API like &quot;unquote_to_bytes&quot; is more<br>
symptom treatment than solution.  Of course something that unquotes a<br>
URL segment unquotes it into bytes; it&#39;s the only sane default because<br>
URL segments found in URLs on the internet are bytes.<br></blockquote><div><br>Yes, URL quoted strings should decode to bytes, though arguably it is reasonable to also use the very reasonable UTF-8 default that urllib.parse.quote/unquote uses.  So it&#39;s really just a question of names, should be quote_to_string or quote_to_bytes that name.  Which honestly... whatever.<br>

<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
So I guess the &quot;hard part&quot; is more meta.  When you have legitimate<br>
backwards compatibility constraints, suboptimal choices made during<br>
protocol design are excusable.  But it just seems really very weird to<br>
design one (WSGI 2) from scratch with such choices when the only reason<br>
to do so is a systematic low-level denial of reality.  Why would we use<br>
(and, worse, by doing so, implicitly promote) such a system in the first<br>
place?<br>
<br>
On the other hand, indignance about the issue shouldn&#39;t rule the day<br>
either.  To me, the most pragmatic thing to do that doesn&#39;t deny reality<br>
would be to use bytes.  It&#39;s also the easiest thing to remember (the<br>
values in the environment are all bytes) and I think we&#39;ll be able to<br>
drive the Py3K stdlib forward in a much saner direction if we choose<br>
bytes than if we choose text to represent things that are naturally more<br>
bytes-like.<font color="#888888"><br></font></blockquote><div><br>I do feel like indignance has played a part here.  And in my brief forays into Python 3 I have been frustrated by the over-textification of APIs.  But... if a compromise works let&#39;s not let those experiences color our choices.<br>

<br>So, here&#39;s my criteria for resolving this particular Python 3 issue:<br><br>* We should not lose information from the request.  Decoding with UTF-8 (without surrogateescape) would be an example.  URL-decoding loses us information currently; which is why I wouldn&#39;t be sad to see it go (though if it was only for that reason I wouldn&#39;t bother -- the unicode issue just makes it serendipitous).<br>

<br>* We shouldn&#39;t produce wildly inaccurate strings.  E.g., decoding something with Latin1 when it&#39;s an implausible encoding.<br><br>* Encoding/decoding errors should only possibly happen at the application level, or maybe middleware if you are playing around with stuff.  Servers specifically should never have them (because they can&#39;t gracefully handle them).<br clear="all">

<br>* We should avoid server configuration with respect to application policy (we&#39;ve avoided it so far, yay!)<br><br>* We should support eclectic application layouts, e.g., an application that sometimes serves Latin-1, sometimes UTF-8 (like if the application proxies requests or serves up legacy content/apps).<br>

</div></div><br>* We should make things as easy to port as possible.  Errors in porting should be loud.<br><br>* As much as possible WSGI should be readable and usable.  Maybe most people will use a library, but we also have a lot of libraries that handle WSGI, and it&#39;s nice that&#39;s been able to happen, so we don&#39;t want to make things any harder than they have to be.  E.g., clearly we should use text environ keys (luckily we don&#39;t have to worry about non-ASCII header names, I guess?)<br>

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