Menu
▾
▴
[privoxy-devel] [ ijbswa-Patches-895531 ] gzip and zlib decompression
|
From: SourceForge.net <no...@so...> - 2007-07-28 09:03:49
|
Patches item #895531, was opened at 2004-02-12 08:26 Message generated for change (Comment added) made by fabiankeil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=311118&aid=895531&group_id=11118 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: new feature Group: None Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Wil Mahan (wmahan) Assigned to: Fabian Keil (fabiankeil) Summary: gzip and zlib decompression Initial Comment: Here is a patch I wrote more than a year ago that allows Privoxy to decompress and filter gzip-compressed data. Sorry about not submitting it earlier, but I dusted it off tonight and thought I'd post it now. To summarize, when we need to filter data sent by a server and it is compressed, this patch allows Privoxy to decompress it, filter, and send the result to the client decompressed. Possible future improvements include re-compressing after filtering but before sending to the client (would this be useful?), and allowing Privoxy to accept compressed data even if the client doesn't. I've tested the patch with servers that send "Content-Encoding: gzip" (e.g. Slashdot), and it seems to be stable. Previously I also tested with zlib compression, but I'm not sure that zlib is ever used in practice anyway. To use: apply the patch run configure with the --enable-zlib option start privoxy and test Note that this patch currently disables Privoxy's default of removing Accept-Encoding headers that allow compression. It doesn't yet include any documentation, but I can add some if this is received well. The patch is against latest CVS, but should apply without major changes to any recent version. Comments are appreciated. ---------------------------------------------------------------------- >Comment By: Fabian Keil (fabiankeil) Date: 2007-07-28 09:03 Message: Logged In: YES user_id=875547 Originator: NO What kind of news are you looking for? As you can read in the comments a modified version of the patch is in CVS since about half a year. ---------------------------------------------------------------------- Comment By: Ryan Hatch (rdhatch) Date: 2007-07-27 22:41 Message: Logged In: YES user_id=1592266 Originator: NO Any news on this patch? I would much rather use Privoxy with gzip support, than prevent-compression. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2007-01-16 03:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Fabian Keil (fabiankeil) Date: 2007-01-03 11:52 Message: Logged In: YES user_id=875547 Originator: NO Apparently it works with mingw32 if one makes sure that zlib.h and zconf.h are found by gcc and that Privoxy can find cygz.dll and cygwin.dll. ---------------------------------------------------------------------- Comment By: Fabian Keil (fabiankeil) Date: 2007-01-01 20:03 Message: Logged In: YES user_id=875547 Originator: NO I just integrated a modified version of Wil's patch, feedback welcome. To test it, recompile with the --enable-zlib configure switch and disable prevent-compression. At the moment there is no way to enable/disable it without recompiling, but it's supposed to work with all sites anyway. Note that it currently doesn't compile with all zlib version out there. I tested it on FreeBSD and confirmed that it compiles on cygwin, but it fails with mingw32. I had to make some changes that affect Privoxy even if --enable-zlib isn't used, so regression testing would be useful even if you're using an unsupported zlib version. ---------------------------------------------------------------------- Comment By: David Schmidt (david__schmidt) Date: 2006-08-18 13:07 Message: Logged In: YES user_id=249980 I'm attaching Roland's version of the patch since it appears to be in his /tmp directory. ;-) ---------------------------------------------------------------------- Comment By: Roland Rosenfeld (roro) Date: 2006-08-05 18:22 Message: Logged In: YES user_id=43129 Okay, the new version of the patch does no longer segfault on every click, but now google does not fully work for me (using privoxy with a forward to a netcache proxy, if this is relevant). Sometimes I can receive the goole start page, but the next click gives me "Error: Invalid gzip header when decompressing" in the log and no output in the browser. So I will stop using it until someone more familiar than me fixes this bug. ---------------------------------------------------------------------- Comment By: Roland Rosenfeld (roro) Date: 2006-08-05 16:46 Message: Logged In: YES user_id=43129 I tried to adapt this patch from 3.1 code to 3.0.3. You'll find the adapted patch at: http://www.spinnaker.de/tmp/privoxy-3.0.3-gzip.patch I didn't do much testing, but up to now it seems to work okay. ---------------------------------------------------------------------- Comment By: Hal Burgiss (hal9) Date: 2004-02-13 03:24 Message: Logged In: YES user_id=322640 William, just so you and other new comers know, part of the discussion will probably be how to deal with current source tree. A group decision was made when 3.0.0 was released that only bugfixes and minor feature enhancements would go in that branch so it would stay stable. Any new features would go in the main trunk aka the devel branch. But, as time has dragged on, little work has been done to keep the two in sync wrt to bugfixes, doc updates, etc. so that main trunk is probably in need of some help. And it doesn't look to change radically any time soon. That leaves us the quandry of living by our own rules and depriving the masses of some good stuff. Or ... Existing personnel has not had much time, and there hasn't been much outside help coming in. ---------------------------------------------------------------------- Comment By: Wil Mahan (wmahan) Date: 2004-02-13 02:50 Message: Logged In: YES user_id=613983 Thanks for the quick response. I'm not very familiar with the state of unstable, but if there's anything else I can do to improve the patch for whichever branch you think is appropriate, just let me know. Within the next few days I plan to post an update that removes the tabs from the patch (oops), adds some documentation to the user manual, and adds entries in the actionsfile templates. -- Wil ---------------------------------------------------------------------- Comment By: Hal Burgiss (hal9) Date: 2004-02-12 16:04 Message: Logged In: YES user_id=322640 Andreas, this is a particularly strong candidate for inclusion IMO, especially considering how far off the unstable/testing branch is for everyday use. .02 ---------------------------------------------------------------------- Comment By: Andreas Oesterhelt (oes) Date: 2004-02-12 10:32 Message: Logged In: YES user_id=78811 William, thanks a lot for sharing your work! I've just finished skimming over the patch and it looks very well done & thoughtfully integrated into our framework. Nice job! Apart from minor cosmetics, inclusion into the actionsfile editor templates, docs and wider testing it looks ready for shipping, I'll post to the devel list shortly about the more general question of how we should deal with the whole array of waiting and very worthwile patches that are rotting on the patch tracker when our stable branch shouldn't be receiving new code except bugfixes, and the trunk is in a state that basically prohibits adding new features. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=311118&aid=895531&group_id=11118 |