[Catalog-sig] Changes to the simple pages

Ian Bicking ianb at colorstudy.com
Thu Jan 21 22:49:14 CET 2010


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 &amp; in
them.

On Tue, Jan 19, 2010 at 6:57 PM, P.J. Eby <pje at telecommunity.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/catalog-sig/attachments/20100121/7c505781/attachment.htm>


More information about the Catalog-SIG mailing list