If you use <base href> that might resolve this problem (pip looks at this, I haven't checked the setuptools code).<div><br></div><div>pip does not use the Setuptools index code, and I don't have unescaping in pip, so the implementations differ in this case. I guess I didn't notice because in tests I didn't encounter any (meaningful) links with &amp; in them.<br>
<br><div class="gmail_quote">On Tue, Jan 19, 2010 at 6:57 PM, P.J. Eby <span dir="ltr"><<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="h5">At 10:21 PM 1/19/2010 +0100, Martin v. Löwis wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>> 2. Make file paths relative (from<br>
>> <<a href="http://pypi.python.org/packages" target="_blank">http://pypi.python.org/packages</a>><a href="http://pypi.python.org/packages" target="_blank">http://pypi.python.org/packages</a><br>
>> Â to ../../packages)<br>
...<br>
> Likewise, #2 should be fine as long as urlparse.urljoin produces the<br>
> correct result using the retrieved-from URL as the base URL. I stress<br>
> this because some web applications treat the urls "foo" and "foo/" as if<br>
> they were interchangeable, and for relative-URL purposes, they are not.<br>
> So, as long as PyPI handles this correctly based on the URL that was<br>
> sent by the *client* (rather than perhaps a canonical URL the client<br>
> "should have" sent), then that will be fine.<br>
<br>
Can you please suggest an example where this could break? If the client<br>
doesn't send an absolute path, it will be incorrect HTTP, no?<br>
</blockquote>
<br></div></div>
No, what I mean is that if PyPI returns *identical* HTML for requests going to "/foo" and "/foo/", then one of those pages will contain incorrect relative URLs.<br>
<br>
I mention this because, at least in the main web interface, going to <a href="http://pypi.python.org/pypi/setuptools" target="_blank">http://pypi.python.org/pypi/setuptools</a> and <a href="http://pypi.python.org/pypi/setuptools/" target="_blank">http://pypi.python.org/pypi/setuptools/</a> produces similar (if not identical) HTML.<br>
<br>
Currently, the relative URLs in such pages are site-absolute, i.e., "/pypi/whatever", so the fact that the two pages are identical isn't a problem. However, if you used pure relative URLs ('../whatever'), then one of the two pages would have incorrect relative URLs.<br>
<br>
So, all I am saying is, please make sure that the generated relative URLs are correct, based not on a canonical form of the URL, but based on whether the client asked for <a href="http://pypi.python.org/simple/setuptools" target="_blank">http://pypi.python.org/simple/setuptools</a> or <a href="http://pypi.python.org/simple/setuptools/" target="_blank">http://pypi.python.org/simple/setuptools/</a> - because if those two URLs return *identical* HTML, *one* of them will be wrong.<br>
<br>
In other words, one of those two pages must have one more '../' in each URL than the other one has for the same URL. Does that make sense now?<br>
<br>
I'm really just saying that the relative URLs must be correct, and reminding you (in case you're not already aware) that the current PyPI code may be relying on its use of "/pypi" relative URLs in order to ignore the trailing-slash issue. And if that's the case, then there will be pages generated with *wrong* relative URLs, unless you remember to test both the '/'-terminated and non-'/'-terminated versions. (Even if just by clicking the links in a browser.)<br>
<br>
</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>
</div>