Fix HTTPError __init__ for cases where fp is None.

The HTTPError class tries to act as a regular response objects for
HTTP protocol errors that include full responses.  If the failure is
more basic, like no valid response, the __init__ choked when it tried
to initialize its superclasses in addinfourl hierarchy that requires a
valid response.

The solution isn't elegant but seems to be effective.  Do not
initialize the base classes if there isn't a file object containing
the response.  In this case, user code expecting to use the addinfourl
methods will fail; but it was going to fail anyway.

It might be cleaner to factor out HTTPError into two classes, only one
of which inherits from addinfourl.  Not sure that the extra complexity
would lead to any improved functionality, though.

Partial fix for SF bug # 563665.

Bug fix candidate for 2.1 and 2.2.

1 files changed, 6 insertions, 2 deletions

diff --git a/Lib/urllib2.py b/Lib/urllib2.py
index 814a2df..2c4a3e1 100644
--- a/Lib/urllib2.py
+++ b/Lib/urllib2.py
@@ -157,13 +157,17 @@ class HTTPError(URLError, addinfourl):
     __super_init = addinfourl.__init__
 
     def __init__(self, url, code, msg, hdrs, fp):
-        self.__super_init(fp, hdrs, url)
         self.code = code
         self.msg = msg
         self.hdrs = hdrs
         self.fp = fp
-        # XXX
         self.filename = url
+        # The addinfourl classes depend on fp being a valid file
+        # object.  In some cases, the HTTPError may not have a valid
+        # file object.  If this happens, the simplest workaround is to
+        # not initialize the base classes.  
+        if fp is not None:
+            self.__super_init(fp, hdrs, url)
 
     def __str__(self):
         return 'HTTP Error %s: %s' % (self.code, self.msg)