Thanks for the test case; fixed in tip now.  If anything goes wrong what should happen is a return value of (quote(script_name), quote(path_info)) -- there&#39;s no combination of request_uri/script_name/path_info that should cause an exception (except bugs).  As you say, there&#39;s no promise that those values are in any way related, and when that is the case it is appropriate to fix it up at the WSGI stage (not necessarily in the WSGI adapter itself).<br>

<br><br><div class="gmail_quote">On Mon, Sep 28, 2009 at 2:34 AM, Graham Dumpleton <span dir="ltr">&lt;<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

2009/9/28 Ian Bicking &lt;<a href="mailto:ianb@colorstudy.com">ianb@colorstudy.com</a>&gt;:<br>
<div class="im">&gt; I tried implementing some code to convert REQUEST_URI (the raw request URL)<br>
&gt; and CGI-style SCRIPT_NAME/PATH_INFO into a raw script_name/path_info.<br>
&gt;   <a href="http://bitbucket.org/ianb/wsgi-peps/src/tip/request_uri.py" target="_blank">http://bitbucket.org/ianb/wsgi-peps/src/tip/request_uri.py</a> (python 2)<br>
&gt;   <a href="http://bitbucket.org/ianb/wsgi-peps/src/tip/request_uri3.py" target="_blank">http://bitbucket.org/ianb/wsgi-peps/src/tip/request_uri3.py</a> (python 3)<br>
&gt; Admittedly the tests are not very complete, I just wasn&#39;t feeling creative<br>
&gt; about test cases.  In terms of performance this avoids being entirely brute<br>
&gt; force, but feels kind of complex.  I&#39;m betting there&#39;s an entirely different<br>
&gt; approach which is faster.  But whatever.<br>
<br>
</div>Got an error:<br>
<br>
 mod_wsgi (pid=4301): Exception occurred processing WSGI script<br>
&#39;/Users/grahamd/Testing/tests/wsgi20.wsgi&#39;.<br>
 Traceback (most recent call last):<br>
   File &quot;/Users/grahamd/Testing/tests/wsgi20.wsgi&quot;, line 80, in application<br>
     environ[&#39;PATH_INFO&#39;])<br>
   File &quot;/Users/grahamd/Testing/tests/wsgi20.wsgi&quot;, line 64, in<br>
request_uri_to_path<br>
     remove_segments = remove_segments - 1 -<br>
qscript_name_parts[-1].lower().count(&#39;%2f&#39;)<br>
 IndexError: list index out of range<br>
<br>
This was an extreme corner case where Apache mod_rewrite was being<br>
used to do stuff:<br>
<br>
RewriteEngine On<br>
RewriteCond %{REQUEST_FILENAME} !-f<br>
RewriteRule ^(.*)$ /wsgi20.wsgi/$1 [QSA,PT,L]<br>
<br>
and Apache was configured to allow encoded slashes. The input would have been:<br>
<br>
REQUEST_URI: &#39;/a%2fb/c/d&#39;<br>
SCRIPT_NAME: &#39;/wsgi20.wsgi&#39;<br>
PATH_INFO: &#39;/a/b/c/d&#39;<br>
<br>
That style of rewrite rule is quite often used with Apache, although<br>
allowing encoded slashes isn&#39;t.<br>
<br>
That SCRIPT_NAME needs to be adjusted is a known consideration with<br>
this rewrite rule. Usually you would use wrapper around WSGI<br>
application which does:<br>
<br>
def _application(environ, start_response):<br>
    # The original application.<br>
    ...<br>
<br>
import posixpath<br>
<br>
def application(environ, start_response):<br>
    # Wrapper to set SCRIPT_NAME to actual mount point.<br>
    environ[&#39;SCRIPT_NAME&#39;] = posixpath.dirname(environ[&#39;SCRIPT_NAME&#39;])<br>
    if environ[&#39;SCRIPT_NAME&#39;] == &#39;/&#39;:<br>
        environ[&#39;SCRIPT_NAME&#39;] = &#39;&#39;<br>
    return _application(environ, start_response)<br>
<br>
If that algorithm is used in WSGI adapter however, would never get the<br>
opportunity to do that though as would already have failed before it<br>
got called.<br>
<font color="#888888"><br>
Graham<br>
</font></blockquote></div><br><br clear="all"><br>-- <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>