<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [Web-SIG] WSGI 2: Decoding the Request-URI</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>I wrote:<BR>
&gt; Applications do produce URI's (and IRI's, etc. that need to be<BR>
&gt; converted into URI's) and do transfer them in media types like<BR>
&gt; HTML, which define how to encode a.href's and form.action's<BR>
&gt; before %-encoding them [4]. But these are not the only vectors<BR>
&gt; by which clients obtain or generate Request-URI's.<BR>
&gt; ...<BR>
&gt; As someone (Alan Kennedy?) noted at PyCon, static resources may<BR>
&gt; depend upon a filename encoding defined by the OS which is<BR>
&gt; different than that of the rest of the URI's generated/understood<BR>
&gt; by even the most coherent application.<BR>
&gt; ...<BR>
&gt; &quot;In practical terms, character-by-character comparisons should be<BR>
&gt; done codepoint-by-codepoint after conversion to a common character<BR>
&gt; encoding.&quot; In other words, the URI spec seems to imply that the<BR>
&gt; two URI's &quot;/a%c3%bf&quot; and &quot;/a%ff&quot; may be equivalent, if the former<BR>
&gt; is u&quot;/a\u00FF&quot; encoded in UTF-8 and the latter is u&quot;/a\u00FF&quot;<BR>
&gt; encoded in ISO-8859-1. Note that WSGI 1.0 cannot speak about<BR>
&gt; this, since all environ values must be byte strings. IMO WSGI<BR>
&gt; 2 should do better in this regard.<BR>
&gt; ...<BR>
&gt; For the three reasons above, I don't think we can assume that the<BR>
&gt; application will always receive equivalent URI's encoded in a<BR>
&gt; single, foreseen encoding.<BR>
<BR>
Did I say 3 reasons? I meant 4: Accept-Charset.<BR>
<BR>
<BR>
Robert Brewer<BR>
fumanchu@aminus.org<BR>
</FONT>
</P>

</BODY>
</HTML>