Why does ob_start('ob_gzhandler') break this website?

Question

I've got a site that throws a Content Encoding Error in the browser if a ob_start('ob_gzhandler') is present. If I remove the statement, it runs fine.

• The site runs off the same framework, server and hosting package as a number of other sites. They all work, regardless of if the statement is in there.
• The statement is in the framework, not the application code, so it is shared by all of the sites.
• There's no difference in the configuration between the working sites and non working site.
• The site runs fine locally, using the exact same code and data.
• You can fetch the site with curl / wget, and the HTML returned renders fine in a browser.
• The response headers are exactly the same, with out without the statement.

I've now removed all of the code on the remote server, and re-uploaded everything. Still no change. The next step would be to re-install the site, and start from scratch, but I don't want to loose all of the data.

Any pointers, suggestions or solutions?

Introject

Does your IDE add any UTF8/UTF16 characters at the start of your document? – Neologize

Do you have this activated ? As said here > You cannot use both ob_gzhandler() and zlib.output_compression. Also note that using zlib.output_compression is preferred over ob_gzhandler(). – Coniology

@Russel Dias no @Coniology The code around the ob_start('ob_gzhandler') checks for that. – Introject

Answer 1

usually I do below and it works for me, give it a try

Write ob_end_clean(); or ob_flush(); at the bottom of the page where you start ob_start();

References:

ob_end_clean();

ob_flush();

Selectman

Interesting. I added while (ob_get_level() > 0) { ob_end_clean() } That fixed it. I'm still wondering why it didn't show up on the other sites, thought. Thanx anyway! – Introject

Answer 2

Just Put this line of code in starting and everything will be fine..

while (ob_get_level() > 0) { ob_end_clean() ; } 

Eustache

Answer 3

If you're using Apache's gzip compression already (which by the looks of it you do, since CSS/JS are compressed as far as I can see), then using ob_start('ob_gzhandler') will compress that compression... and the browser won't be able to handle it.

I'm speaking under correction of course as I've always used Apache to do it for me, but it looks like you're double gzipping things, that's why it works without the "ob_gzhandler" statement.

Check your .htaccess files on the other sites and compare it with the site you're running that has the same problem as I can't see that you're running Drupal on zacoders.net and jadeit.co.za, just on jadeit.co.za which makes me think they're not the same framework as you said they are? shrug

Posen

Just to add on to my answer here, the reason why curl returns the website normally is because (again, AFAIK) it doesn't support gzip thus the server/software will give the site "as is". But with browsers that do support gzip and tell the server they support it, will get back the gzipped-zipped content and can't deflate it properly. – Posen

You are right in saying that it will compress the compressed data, but I prevented it from happening by doing if (ob_get_level() === 0) { ob_start('ob_gzhandler'); } – Introject

zacoders runs on backend-php, as does the actualy backend site and jrgns.net. I also use it at the company I work for. I haven't had a chance to port jadeit.co.za to it... :) – Introject

Well, try disabling Apache's gzip then (using .htaccess if Texo allowed that) and see if it works. And AFAIK, ob_get_level only checks if ob_start has been called before. It doesn't stop the page from being gzipped the first time since ob_start() was called before the ob_get_level check so that if statement will always be true and thus always compress the compressed page. – Posen

ob_get_level returns the current output buffering level. If it's > 0 without you calling ob_start, you know that PHP is doing the gzipping. I managed to sort out the issue by just closing of all output buffering before ending the script. But this is the funny part. When a script ends, PHP automatically flushes all output buffers one by one. For all the other sites this didn't cause any problems. For this one it did. Doing it explicitly solved the problem, but I'm still not sure what the exact problem is! :) – Introject