Fixed  (PHP bug) XF and gzip handler issue


Well-known member
I think this may have gotten overlooked in another thread of mine.

I had reported some screwy issues with XF that were style-related--a password feature would not work, the XF logo was not animated in the admin control panel, etc..

What it turned out to be was that the XF coding was not compatible with the gzip setting I used on our server. For several years, I have used the following in htaccess to gzip-compress our outgoing HTML data to browsers, and it saved us a lot of bandwidth and decreased page loading times:

php_value output_handler ob_gzhandler
There is something gzip is doing that does not "play nice" with the code in XF.

My initial thought is that it may be a result of compressed and/or "minified" CSS or JS files. I have not dug into the code enough to see if that is the case. I do know that the issues were not enough to cripple the forum entirely (other than the "lost password" link), but a few of the nice extras just were not working as they should have.

For now I had to disable the gzip in our XF forum directories.

I also do not know if the Apache module mod_gzip would cause the same problem. Our host may have added that option for us--back when I first did this via the PHP route, they did not offer that for us. If they do have it available, I may enable it and see if the issue can be repeated there as well.

I could see adding gzip support in future XF versions as well, like vBulletin does. Although I would not ship XF to have it set to "on" by default--you can imagine what happens when you have two gzip operations on top of each other! ;)

If the developers can't duplicate it here (or want to), let me know and I can setup a test version on one of my servers. It should be possible with most PHP/Apache configurations to turn it on via htaccess like I did above.


XenForo developer
Staff member
XenForo does ship with gzip support enabled by default, and we don't provide a user option to disable it (why would anyone ever want to not run it?) but the system should detect that the server is already applying gzip compression at the server level and disable XF's own system. It sounds like you've found a case where it's not happening.

Could you open a support ticket with some server details so we can investigate please?


Well-known member
Kier, I'd be happy to open a ticket. If I can't get to it this evening, I'll get to it in the morning. Thanks much!


Well-known member
Just to add something briefly: this is a very isolated case. Several years ago, we did not have mod_deflate available on Apache, and we discovered we could use "php_value output_handler ob_gzhandler" to compress outbound files. I doubt there are many that use this method, but you never know if someone has custom scripting for a site, and may innocently have this in their htaccess file.


Well-known member
PHP bug reported in 2006 and apparently still not resolved!

Thanks for the update, much appreciated!