urllib2 doesn't grok URLs w/ user/passwd
SF seems to be down for some unscheduled reason. Posting here just so I don't completely forget about it should I exit my web browser before SF is back up... urllib2.urlopen("http://foo@www.python.org/") fails (at least in part) because it fails to separate the username and password from the hostname. Trying to open http://foo:bar@www.python.org/ reveals other shortcomings in its url parsing. It seems to me the syntactic bits shouldn't be difficult to resolve using urllib.spluituser(). I'm much less clear what to do with the username and password once they've been separated from the hostname. Skip
On Tuesday 30 December 2003 04:03 pm, Skip Montanaro wrote:
Presumably they need to be kept somewhere and sent in the Authorization header in case the server returns a 401 error and challenge (or a proxy returns a 407 error and challenge) -- or maybe the Authorization header (with the base 64 encoding of user:pass) can be sent even as part of the first request to speed things up (assuming an authorization scheme of Basic). RFC 2617, I believe. urllib2's architecture delegates authorization to separate components, of course, so I guess the userid and password should just be handed over to such components if they're present, but I haven't looked into that in detail. Alex
This is what the ever-popular old urllib does.
Me neither. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 30 Dec 2003, Alex Martelli wrote:
urllib2 already knows about this syntax for proxy auth (ProxyHandler.proxy_open). If somebody fixes this (assuming it needs fixing -- I haven't read what the standards say), note that the Basic authentication logic is duplicated, and perhaps broken in one place, which should probably be fixed at the same time: http://www.google.com/groups?threadm=87d6dq2jx0.fsf%40pobox.com If nobody does it first, I'll fix it *eventually* (I'm lazy about configuring a local proxy and web server...). BTW, is somebody planning a 2.3.4 (or 2.2.4)? When? That would motivate me to fix urllib2 bugs sooner. John
I plan a 2.3.4 in the April-May-June timeframe. This will _probably_ be the final release of 2.3 before 2.4, although we could have a 2.3.5 if there's a need for it at the end of the year (shortly after 2.4 is done would be my pick). I don't know that we'd have a need for many more 2.3 releases after that - particularly since, at the moment at least, 2.4 seems to be continuing down 2.3's conservative path as far as potentially dangerous changes. Note that, aside from major bug fixes, I'm not particularly driven by volume of bug fixes for selecting a release schedule - mostly it's driven by my own personal estimation of when I'm likely to have time available to do the release. Each release I do seems to take less time (yay for automation! boo that the major part of the automation seems to have gone missing somehow in the laptop theft/recovery of data from tape.... ah well). Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Tuesday 30 December 2003 04:03 pm, Skip Montanaro wrote:
Presumably they need to be kept somewhere and sent in the Authorization header in case the server returns a 401 error and challenge (or a proxy returns a 407 error and challenge) -- or maybe the Authorization header (with the base 64 encoding of user:pass) can be sent even as part of the first request to speed things up (assuming an authorization scheme of Basic). RFC 2617, I believe. urllib2's architecture delegates authorization to separate components, of course, so I guess the userid and password should just be handed over to such components if they're present, but I haven't looked into that in detail. Alex
This is what the ever-popular old urllib does.
Me neither. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 30 Dec 2003, Alex Martelli wrote:
urllib2 already knows about this syntax for proxy auth (ProxyHandler.proxy_open). If somebody fixes this (assuming it needs fixing -- I haven't read what the standards say), note that the Basic authentication logic is duplicated, and perhaps broken in one place, which should probably be fixed at the same time: http://www.google.com/groups?threadm=87d6dq2jx0.fsf%40pobox.com If nobody does it first, I'll fix it *eventually* (I'm lazy about configuring a local proxy and web server...). BTW, is somebody planning a 2.3.4 (or 2.2.4)? When? That would motivate me to fix urllib2 bugs sooner. John
I plan a 2.3.4 in the April-May-June timeframe. This will _probably_ be the final release of 2.3 before 2.4, although we could have a 2.3.5 if there's a need for it at the end of the year (shortly after 2.4 is done would be my pick). I don't know that we'd have a need for many more 2.3 releases after that - particularly since, at the moment at least, 2.4 seems to be continuing down 2.3's conservative path as far as potentially dangerous changes. Note that, aside from major bug fixes, I'm not particularly driven by volume of bug fixes for selecting a release schedule - mostly it's driven by my own personal estimation of when I'm likely to have time available to do the release. Each release I do seems to take less time (yay for automation! boo that the major part of the automation seems to have gone missing somehow in the laptop theft/recovery of data from tape.... ah well). Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
participants (6)
-
Alex Martelli -
Anthony Baxter -
Guido van Rossum -
John J Lee -
Skip Montanaro -
Terry Reedy