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.)
_______________________________________________
Catalog-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/catalog-sig
