Buggy code:

"""
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return
        newurl = urlparse.urljoin(req.get_full_url(), newurl)
"""        

You might end up being redirected to some "strange" location if for some reason the value of "location" is C:\boot.ini, and you urlparse.urljoin the current URL with that one, you end up with C:\boot.ini . When the urllib2 library opens that, it will open a local file. What I did to fix it, is to verify that the protocol of the newurl is http or https.

"""
        correct_protocol = newurl.startswith('http://')  or newurl.startswith('https://') 
        if not correct_protocol:
            return

"""

The fix should be applied just below the dangerous urlparse.urljoin.

In Python 2.7a3+, trunk:78165 the code is as follows: (note that there is a segment of code to fix malformed URLs)

"""
        if 'location' in headers:
            newurl = headers.getheaders('location')[0]
        elif 'uri' in headers:
            newurl = headers.getheaders('uri')[0]
        else:
            return

        # fix a possible malformed URL
        urlparts = urlparse.urlparse(newurl)
        if not urlparts.path:
            urlparts = list(urlparts)
            urlparts[2] = "/"
        newurl = urlparse.urlunparse(urlparts)

        newurl = urlparse.urljoin(req.get_full_url(), newurl)

"""

The problem is still there in 2.7:

>>> urlparts = urlparse.urlparse('C:\\boot.ini')
>>> urlparts
('c', '', '\\boot.ini', '', '', '')
>>> if not urlparts.path:
...     urlparts = list(urlparts)
...     urlparts[2] = "/"
... 
>>> urlparts
('c', '', '\\boot.ini', '', '', '')
>>> newurl = urlparse.urlunparse(urlparts)
>>> newurl
'c:\\boot.ini'
>>> newurl = urlparse.urljoin( 'http://host.tld/spam/eggs.py', newurl)
>>> newurl
'c:\\boot.ini'
>>>

I disagree with this bug report.

First the responsibility of checking if something is not  malicious URL lies at the application/client end, urllib in its redirection never urlopen()'s the redirected url, so you are not harmed in anyway.
If you wanted to be extra careful of the BAD Server, you can always subclass the redirection methods and use those handlers.

Closing this bug as won't fix.