Steve tracked down the root of the problem that is causing MagpieRSS to run out of memory after upgrading to 4.3.2. It lies in my (apparently dodgy) patch to Snoopy to add gzip support.

Temporary Solution

To turn off gzip encoding (and thereby avoid this bug) add: define('MAGPIE<em>USE</em>GZIP', false);

to the top of your script. ### Explanation

After much hair pulling trying to get gzip encoding working in PHP, I found this magic recipe in comments attached to gzencode: ` $results = substr($results, 10); $results = gzinflate($results);`

Seems you had to strip off the gzip header to make it work. This was confirmed when I found Simon’s httpClient. Apparently this is changed in 4.3.2, and stripping the first 10 characters leads eventually (through a yet untraced path) to an out of memory error.

Next Steps

Does anyone have any info about this? Any suggestions on a good way to support 4.3.2 and pre-4.3.2 PHPs? Gzip encoding really isn’t an optional feature in a modern aggregator, so turning it off is a short term solution. ### Update 6/25 2:16

Okay, so I’ve got PHP 4.2.3 locally now (via Marc Liyanage’s excellent package), and I’m seeing similar behaviour. I don’t actually get an out of memory error, but I can see memory usage spike (with iPulse) and I get a warning about a gzinflate buffer error. Unforunately removing “$results = substr($results, 10);” does not fix the problem for me. So currently the only solution is to turn gzip encoding off :(### Curiouser and Curiouser

So removing the substr() call changed the error message form “gzinflate(): buffer error”, to “gzinflate(): data error”. However only for certain websites! Files served with gzip encoding from some sites (like mine) work, but from others, it doesn’t. Ack.