I have applied and tested this patch. The code seems to be
correct. Fetching gzipped data from www.mozilla.org works as it
should. 

What the patch does is change Accept-Encoding from identity to
identity,gzip;q=0.9. That hints the HTTP server that we can handle
gzipped data. Some servers take the hint and sends us gzipped data
(www.mozilla.org is such a server). We check if that is so by checking
the Content-Encoding header in the HTTP response headers. If that is
set to gzip, the body of the response is gzipped data.

What then happens is that we create a hacked GzipFile object that
works on a wrapped version of the HTTPResponse itself. It has to be
hacked, because GzipFile works by seeking to the end of the file
object. That ofcourse does not work for us, because the whole file is
not available. But this hacked version employs some kind of StringIO
trick so that instead of seeking to the end of the file, it seeks to
the end of the read data.

So HTTPResponse aquires a reference to GzipFile2 which it reads
from. GzipFile2 in turn, has a reference to GzipedHTTPIO (the wrapper)
which in turn references the HTTPResponse. The read method in
HTTPResponse invokes the read method on GzipedFile2 which invokes the
read of GzipedHTTPIO which invokes the read of HTTPResponse. But
GzipedHTTPIO breaks the potential recursion by specifying raw=True
which means that it want HTTPResponse to feed it uncompressed data. A
very, very clever scheme.

I hope this information is useful. It took me way to long to get this
far. Originally I thought that this patch should be rejected because it
is just to damn complicated, but then I saw that the rest of
httplib.py is equally complicated. :)