Deflate decompression error with PHP 5.3.0 and IIS 7

[amattie]

When using the HTTP class with IIS 7 and PHP 5.3.0 with deflate compression is enabled (disabled by default on IIS 7), it seems that deflate decompression doesn't work. The error I'm seeing is:

Warning: gzuncompress() [function.gzuncompress]: data error in C:\Projects\WordPress\wp-includes\http.php on line 1820

The response stream is properly compressed with deflate compression according to other tools I've used to test this. It seems that the error has something to do with the functionality in the relatively recent implementation of the WP_Http_Encoding->compatible_gzinflate method. If I change the WP_Http_Encoding->decompress method to simply call gzinflate on the first line instead of WP_Http_Encoding::compatible_gzinflate, I don't see the error anymore and the HTTP class appears to properly decompress the deflate stream.

I'm not sure if this error is related specifically to IIS 7 or if instead the broken functionality that necessitated the addition of the compatible_gzinflate method has been fixed in a recent version of PHP.

[amattie]

To be clear here, I'm running WordPress under IIS 7 with PHP 5.3.0. The content I'm requesting is also being served from IIS 7 (ASP.NET app, although I don't believe ASP.NET has anything to do with it). I realized that there could be confusion without that bit of information.

[dd32]

Do you have any public facing URL's which i can test against?

Compatible_gzinflate() is required due to every single implementation of deflate in most webservers differ in the leading data.

It might be a viable option to simple add this to the top of the inflate function: Ie. try it before reverting to the rest.. Even though the function does check straight up if theres a proper prefix in the file..

if ( false !== ($data = @gzdeflate($in_data))) 
   return $data;

[amattie]

I don't have anything public to test this against. It's a server-level setting in IIS 7, so when I turn it on on our public-facing production servers, it'll break for all the applications for the users who are already hitting our servers with that class. Again, deflate is off by default on IIS w/o much of a reason to enable it unless then know about PHP < 6 not supporting gzip decoding, so I think that's why no one else has noticed it until now.

Adding the following to the top of the compatible_gzinflate fixes the issue for my specific circumstances:

if ( false !== ($data = gzinflate($gzData))) 
	return $data;

The fix remains untested for other server configurations.

[amattie]

Fix for deflate compression from IIS 7

[dd32]

The fix remains untested for other server configurations.

Without a @ in there, The function will emit warnings about incorrect data from a fair chunk of other servers.

I'll try to get IIS7 up and running today and see if i can see whats happening.

[miqrogroove]

I get this error all the time on my LAMP server.

[05-Dec-2009 14:35:46] PHP Warning: gzuncompress() [<a href='function.gzuncompress'>function.gzuncompress</a>]: data error in wp-includes/http.php on line 1792
[05-Dec-2009 14:35:46] PHP Warning: gzinflate() [<a href='function.gzinflate'>function.gzinflate</a>]: data error in wp-includes/http.php on line 1787
[05-Dec-2009 14:35:47] PHP Warning: gzuncompress() [<a href='function.gzuncompress'>function.gzuncompress</a>]: data error in wp-includes/http.php on line 1792
[05-Dec-2009 14:35:47] PHP Warning: gzuncompress() [<a href='function.gzuncompress'>function.gzuncompress</a>]: data error in wp-includes/http.php on line 1792

My last ticket about that was closed because nobody knew how to reproduce the issue. Does anyone have a test case for it yet?

[dd32]

Does anyone have a test case for it yet?

Can you post the site which is causing it? Until i can test against a server which is causing it, theres not much I can do. I cant setup a server to test against until i know which server, And the same goes for anyone else, Unless they know the server or site to test against thats causing it..

I can however tell you its a chance of 3 things:

1. Site saying its compressed when its not
2. Site saying its compressed with deflate when its compressed with something else
3. Site saying its compressed with deflate (but like many servers) strips off the deflate compression header before sending it.

(I didnt have the CD i thought i had, So i've not setup a test IIS7 install yet)

[miqrogroove]

Replying to dd32:

Can you post the site which is causing it?

​http://blogyul.miqrogroove.com/

All I can tell you is that it seems to be something to do with with the admins, because when we are logged in and working on the blog, that's when most of the errors appear.

[dd32]

Can you post the site which is causing it?

​http://blogyul.miqrogroove.com/

Not the site i wanted :) - That error pops up because WordPress is fetching another web document from another server, That other server is what causes the message.

[miqrogroove]

Replying to dd32:

other server

All I have is the error log. Where do I find this other server?

[dd32]

All I have is the error log. Where do I find this other server?

You need to know what is calling wp_remote_get() and what URL its fetching.

You can try installing my Core Control plugin (​http://wordpress.org/extend/plugins/core-control/) and enabling the outgoing HTTP Logger, That may give you some explanation on it.

[miqrogroove]

Didn't work :/ The HTTP Log only goes back 7 minutes, and the error I'm looking for was 10 mins ago. My site makes a $*load of requests apparently.

[miqrogroove]

Also, the delete button stopped working.

[miqrogroove]

oh now I see I'm deleting progressively older entries. Sorry but this is no good. My server made several hundred requests at the time of the error.

[dd32]

What on earth is your server making hundreds of requests to? Sounds like you've got something worse to worry about to me..

I've got a IIS7.5 install here, But cannot get it to return compressed content to WordPress no matter how hard i try, Other browsers are OK, but just not WP, even with the proper deflate, gzip and compress Accept headers set. - For now i'll have to give up trying to debug this one.

[miqrogroove]

Many of them were HEAD requests back to my site. Anyway, it looks I would need a proper try/catch hack to get something useful out of this.

[amattie]

Replying to dd32:

I've got a IIS7.5 install here, But cannot get it to return compressed content to WordPress no matter how hard i try, Other browsers are OK, but just not WP, even with the proper deflate, gzip and compress Accept headers set. - For now i'll have to give up trying to debug this one.

I found a production IIS 7 server that we can use for the purposes of debugging this issue. I'll have it up w/in a day and post back here once it's ready.

[dd32]

Related: #11600

Sounds like that could be the same case here. Where the deflation method IIS7 uses is a RAW deflate, rather than a HTTP deflate, Technically the same thing, just http deflate has extra meta data (headers and a footer) defining the type of document.

Patch on that ticket basically does what has been posted here.

[hakre]

For advances debugging purposes, consider hanging in a hook on the php error/warning. I attached some code I have running on a site that reports me errors. But I did some additional hacks inside the codebase to return me the URLs of RSS feeds that actually reported errors. But I could easily integrate them with log_error or trigger_error or the like. Maybe that is of use to you since the backtrace often contains some usefull information.

[hakre]

Own Error Handler and Error Configuration Class to drop into wp-config.php

[nacin]

See #11600, [12642], [12644]