httplib is not v6 compatible, is this going to be fixed?
As the link below shows httplib can't handle an IPv6 address, it checks for a port number by checking for a : but this simply cuts the IPv6 address in two and tries to set the port variable as nonsense. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81926#c2 Are there any plans to rectify this, or even an alternative version of httplib kicking about that can handle IPv6. Regards, David.
David> As the link below shows httplib can't handle an IPv6 address, it David> checks for a port number by checking for a : but this simply cuts David> the IPv6 address in two and tries to set the port variable as David> nonsense. David> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81926#c2 David> Are there any plans to rectify this, or even an alternative David> version of httplib kicking about that can handle IPv6. I just checked in a fix for this (it was a one-character change, not including unit test update). I don't know if there is a Python bug report open which now needs to be closed. Considering the ease of the fix, I sort of think not (otherwise it would have been fixed long ago). Note that in general we have plenty of other things to do with our time without monitoring other projects' bug trackers looking for possible Python bug reports. If they aren't reported on SF we won't here about them. (The Debian folks routinely open SF items when Python bug reports wind up in the Debian tracker.) -- Skip Montanaro Got spam? http://www.spambayes.org/ skip@pobox.com
Have you actually tested it, cus I made my own fix than was at least and additional 7 lines.... David. On Tue, 14 Sep 2004, Skip Montanaro wrote:
David> As the link below shows httplib can't handle an IPv6 address, it David> checks for a port number by checking for a : but this simply cuts David> the IPv6 address in two and tries to set the port variable as David> nonsense.
David> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=81926#c2
David> Are there any plans to rectify this, or even an alternative David> version of httplib kicking about that can handle IPv6.
I just checked in a fix for this (it was a one-character change, not including unit test update). I don't know if there is a Python bug report open which now needs to be closed. Considering the ease of the fix, I sort of think not (otherwise it would have been fixed long ago). Note that in general we have plenty of other things to do with our time without monitoring other projects' bug trackers looking for possible Python bug reports. If they aren't reported on SF we won't here about them. (The Debian folks routinely open SF items when Python bug reports wind up in the Debian tracker.)
-- Skip Montanaro Got spam? http://www.spambayes.org/ skip@pobox.com
David> Have you actually tested it, cus I made my own fix than was at David> least and additional 7 lines.... I don't have access to ipv6. I used the ipaddr:port combination in the RedHat bug report as a test input. Here's the change to httplib.py. Replace: i = host.find(':') with i = host.rfind(':') Like I said, it was a one-character fix. rfind() looks from the back of the host/port combination for the colon separating the host and port. Since port numbers can't contain colons, the first colon found from the back has to be the colon separating the host-or-address from the port number. Here's the change to the test case (Lib/test/test_httplib.py). After the for loop that checks for invalid ports, add this analogous for loop that checks valid host/port combinations: for hp in ("[fe80::207:e9ff:fe9b]:8000", "www.python.org:80", "www.python.org"): try: h = httplib.HTTP(hp) except httplib.InvalidURL: print "InvalidURL raised erroneously" The test case failed before applying the patch and succeeded after. According to the principals of I test-driven development, I'm done until another bug surfaces. In short, I've done what I can to fix the obvious problem. Drilling down any deeper than that is impossible for me. As I indicated, I have no ipv6 access. If you test it out and still find problems, please submit a bug report on SF. Please *don't* follow up to python-dev. It's not the appropriate place to discuss the ins and outs of specific patches. I only did so because that was the easiest way to tell the other developers that I'd applied a fix for the problem. back-to-my-paying-job-ly, y'rs, Skip
At 12:12 PM 9/14/04 -0500, Skip Montanaro wrote:
Here's the change to the test case (Lib/test/test_httplib.py). After the for loop that checks for invalid ports, add this analogous for loop that checks valid host/port combinations:
for hp in ("[fe80::207:e9ff:fe9b]:8000", "www.python.org:80", "www.python.org"):
Here's the test case that's missing, then: "[fe80::207:e9ff:fe9b]"
Phillip> Here's the test case that's missing, then: Phillip> "[fe80::207:e9ff:fe9b]" Whoops. Fixed. Skip
Skip Montanaro wrote:
Phillip> Here's the test case that's missing, then:
Phillip> "[fe80::207:e9ff:fe9b]"
Whoops. Fixed.
The code was still incorrect. The square brackets don't belong to the host name - they are part of the URL syntax. Before passing them to the socket module, they need to be stripped off. I have now changed httplib to do that right when parsing host:port. Regards, Martin
And where can we get a copy of this new 'official' httplib? David. On Tue, 14 Sep 2004, [ISO-8859-1] "Martin v. L�wis" wrote:
Skip Montanaro wrote:
Phillip> Here's the test case that's missing, then:
Phillip> "[fe80::207:e9ff:fe9b]"
Whoops. Fixed.
The code was still incorrect. The square brackets don't belong to the host name - they are part of the URL syntax. Before passing them to the socket module, they need to be stripped off. I have now changed httplib to do that right when parsing host:port.
Regards, Martin
Martin v. Löwis wrote:
David G Mills wrote:
And where can we get a copy of this new 'official' httplib?
As usual: In the CVS.
As well as in 2.4b1, and, I assume 2.3.5, assuming the fix gets backported. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony> ... and, I assume 2.3.5, assuming the fix gets backported. I missed this as well. Will backport. Skip
participants (5)
-
"Martin v. Löwis" -
Anthony Baxter -
David G Mills -
Phillip J. Eby -
Skip Montanaro