On Sat, Jul 17, 2010 at 5:57 AM, Armin Ronacher <span dir="ltr">&lt;<a href="mailto:armin.ronacher@active-4.com">armin.ronacher@active-4.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 class="im">
On 7/17/10 9:15 AM, Ian Bicking wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
This is an Apache-specific issue.  It definitely doesn&#39;t apply to<br>
paste.httpserver, I doubt CherryPy or wsgiref.  I don&#39;t really know how<br>
Nginx or other servers work.<br>
</blockquote></div><br>
This will be an issue for every server that...<br>
<br>
 * supports unicode filesystems<br>
 * decides to do internal mapping based on URIs and not IRIs<br></blockquote><div><br>I think specifically it&#39;s hard to go back and forth between URL-encoded and decoded paths, so if a system parses the decoded path then it&#39;s difficult to go back to a raw form.  For example Paste includes several URL mappers, and they would require (minor) rewriting; but then they can be rewritten so it&#39;s not as concerning.  Apache cannot be rewritten to parse the encoded URL.  I think working on the encoded URLs is a better representation of HTTP, and HTTP URLs, and of browser behavior... but there is a legacy concern.<br>

<br>I don&#39;t think IRI or URI matters in this case; by decoding you *could* transcode URLs from UTF-8 to some local encoding, but that&#39;s not the issue I see us encountering here, it&#39;s really the more simple issue of URL encoding.<br>

</div></div><br>(I should say I appreciate this concrete concern; it keeps us grounded when we discuss HTTP *specifically*, not bytes-v-unicode generally)<br><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>