If you use <base href> that might resolve this problem (pip looks at this, I haven't checked the setuptools code).
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 & in them. On Tue, Jan 19, 2010 at 6:57 PM, P.J. Eby <[email protected]> wrote: > At 10:21 PM 1/19/2010 +0100, Martin v. Löwis wrote: > >> >> 2. Make file paths relative (from >> >> <http://pypi.python.org/packages>http://pypi.python.org/packages >> >> Â to ../../packages) >> ... >> > Likewise, #2 should be fine as long as urlparse.urljoin produces the >> > correct result using the retrieved-from URL as the base URL. I stress >> > this because some web applications treat the urls "foo" and "foo/" as if >> > they were interchangeable, and for relative-URL purposes, they are not. >> > So, as long as PyPI handles this correctly based on the URL that was >> > sent by the *client* (rather than perhaps a canonical URL the client >> > "should have" sent), then that will be fine. >> >> Can you please suggest an example where this could break? If the client >> doesn't send an absolute path, it will be incorrect HTTP, no? >> > > 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. > > I mention this because, at least in the main web interface, going to > http://pypi.python.org/pypi/setuptools and > http://pypi.python.org/pypi/setuptools/ produces similar (if not > identical) HTML. > > 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. > > 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 http://pypi.python.org/simple/setuptools or > http://pypi.python.org/simple/setuptools/ - because if those two URLs > return *identical* HTML, *one* of them will be wrong. > > 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? > > 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.) > > -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker
_______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
