This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author orsenthil
Recipients benjamin.peterson, eric.araujo, jjlee, ndim, orsenthil, pitrou, sergiomb2, tlocke
Date 2010-04-12.05:10:58
SpamBayes Score 1.1864176e-06
Marked as misclassified No
Message-id <1271049062.18.0.00751937534362.issue2987@psf.upfronthosting.co.za>
In-reply-to
Content
With respect to msg98314 (http://bugs.python.org/msg98314) referenced in this bug, which I thought is easy to handle, does not appear so. It is bit tricky.

The problem is the relative url is given of the format '07.11.2009-9:54:12-1.jpg' and urlparse wrongly assumes that it is VALID url with the scheme as 07.11.2009-9 ( Surprisingly, this falls under valid characters for a URL Scheme, but we know that there no url scheme like that).

But when you give ./07.11.2009-9, ./ is identified a relative path and urljoin happens properly. 

My inclination for this specific msg9814, is the allow the user to give the proper path like ./07.11.2009-9 or use urljoin from different directory, images/07.11.2009-9 and this should handle it.

This date-time relative url is not a typical scenario, but for  typical scnerios, urlparse behaves as expected.

>>> x = 'http://a.b.c'
>>> urlparse.urljoin(x,'foo')
'http://a.b.c/foo'
>>> urlparse.urljoin(x,'./foo')
'http://a.b.c/foo'
>>> 

I shall provide my comments on the IPv6 parse in next msg.
History
Date User Action Args
2010-04-12 05:11:02orsenthilsetrecipients: + orsenthil, jjlee, pitrou, benjamin.peterson, ndim, eric.araujo, sergiomb2, tlocke
2010-04-12 05:11:02orsenthilsetmessageid: <1271049062.18.0.00751937534362.issue2987@psf.upfronthosting.co.za>
2010-04-12 05:11:00orsenthillinkissue2987 messages
2010-04-12 05:10:58orsenthilcreate