Issue 7097: urlparse.urljoin of simple "http://" and "somedomain.com" produces incorrect result (original) (raw)

Created on 2009-10-10 17:40 by ssteiner, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (4)
msg93834 - (view) Author: steve steiner (ssteiner) Date: 2009-10-10 17:40
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from urlparse import urljoin >>> urljoin("http://", "somedomain.com") 'http:///somedomain.com' Note the three leading slashes, should be "http://somedomain.com"
msg93836 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2009-10-10 18:26
urlparse.urljoin() is meant to join together a base URL with other URL parts. The protocol is part of the base URL and thus not supported by urlparse.urljoin().
msg151929 - (view) Author: Mark Nottingham (mnot) Date: 2012-01-25 01:41
http: and http:// are both valid base URIs; see RFC3986. More to the point, it's a useful thing to use a scheme as a base URI; many users omit the HTTP:// from their URIs.
msg152273 - (view) Author: Senthil Kumaran (orsenthil) * (Python committer) Date: 2012-01-29 22:46
>>> urljoin("http://", "//somedomain.com") results in "http://somedomain.com" So, I wonder if this way to specify the relative url properly and not the base-url. The test suite of urlparse tries to follow all the advertised scenarios for RFC3986 and also some more tests (which are usually discovered by de-facto scenarios of how other clients (mainly browsers) deal with it. If there is a browser behavior which we should emulate, without breaking existing code, we should consider this, otherwise we could leave this in invalid state. Thanks!
History
Date User Action Args
2022-04-11 14:56:53 admin set github: 51346
2012-01-29 22:46:58 orsenthil set nosy: + orsenthilmessages: +
2012-01-25 01:41:18 mnot set nosy: + mnotmessages: +
2009-10-10 18:26:34 brett.cannon set status: open -> closednosy: + brett.cannonmessages: + resolution: not a bug
2009-10-10 17:40:13 ssteiner create