[Catalog-sig] Changes to the simple pages

P.J. Eby pje at telecommunity.com
Wed Jan 20 01:57:50 CET 2010


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.)



More information about the Catalog-SIG mailing list