Patches item #1243678, was opened at 2005-07-23 20:51 Message generated for change (Comment added) made by sonderblade You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Library (Lib) Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Moonz (mooonz) Assigned to: Nobody/Anonymous (nobody) Summary: httplib gzip support Initial Comment: Add gzip support for httplib. It seems to work correctly - according to the tests I did done, but some points should be altered (I think to the putrequest method, where I didn't change anything - except the two lines of comments who said that the gzip support is not included) ---------------------------------------------------------------------- Comment By: Bj�rn Lindqvist (sonderblade) Date: 2007-03-12 01:40 Message: Logged In: YES user_id=51702 Originator: NO 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. :) ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-09-01 00:38 Message: Logged In: YES user_id=1188172 This will need documentation and test suite changes, too. ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 20:54 Message: Logged In: YES user_id=826215 There's no uploaded file! You have to check the checkbox labeled "Check to Upload & Attach File" when you upload a file. In addition, even if you *did* check this checkbox, a bug in SourceForge prevents attaching a file when *creating* an issue. Please try again. (This is a SourceForge annoyance that we can do nothing about. :-( ) ---------------------------------------------------------------------- Comment By: Moonz (mooonz) Date: 2005-07-23 20:54 Message: Logged In: YES user_id=826215 It's better with the patch ;) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1243678&group_id=5470
_______________________________________________ Patches mailing list Patches@python.org http://mail.python.org/mailman/listinfo/patches
