"ob_gzhandler" on the same server not always supported

Asked

Viewed 89 times

4

On the same hosting server, some accounts support ob_gzhandler and send the compression page to the browser:

/* Sending gz-encoded data to web browsers
 * that support compressed web pages
 */
ob_start("ob_gzhandler");

But other accounts with the code above fail and trigger the following error:

Content Encoding error

The page you are trying to open cannot be displayed because it uses an unsupported or invalid form of compression.
Contact those responsible for the site to inform them about this problem.

Question

How to discern the cause of invalid encoding error?

Note: The PHP configuration for both domains is rigorously the same, just like the Apache directives.

  • The script that generates the error is also exactly the same for all accounts?

  • Maybe I’m talking nonsense, is that really the settings are on the users in the right way? I mean if the server is "virtual" maybe the access settings are not pointed correctly. I think a simple phpinfo(); tested on each server would provide you with the necessary information.

  • @Guilhermenascimento This was one of the first things to be analyzed. The result of phpinfo() is just like for all the accommodation concerned. :)

  • @Andréribeiro No, the error comes in all projects of the same file responsible for debiting the web-site to the browser. But from project to project this file has some differences given its antiquity.

  • @Zuul Take a look in this answer on Soen. I think that might be your problem.

  • In the Apache Environment what he returns in HTTP_ACCEPT_ENCODING? 'Cause if you’re sure they both come back something like: gzip, deflate, lzma, sdch then I will assume that the problem is in the script, I will assume one thing, when uploading the file to another server maybe FTP used BINARY instead of ASCII, or so you used some online editor that encoded your document with UTF8 with GOOD instead of UNWELL. It’s just a theory.

Show 1 more comment

1 answer

1

For my particular case, the problem was in the definition of page headers, where we scripts with the problem of triggering the "Content Encoding" error, the headers were being set after the opening of the buffer outgoing:

ob_start("ob_gzhandler");

$expires = 2678400;
header("Pragma: public");
header("Cache-Control: maxage=".$expires);
header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$expires) . ' GMT');
header('Content-Type: text/html; charset=ISO-8859-1');

To resolve, the headers were set first, and the buffer outgoing second:

$expires = 2678400;
header("Pragma: public");
header("Cache-Control: maxage=".$expires);
header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$expires) . ' GMT');
header('Content-Type: text/html; charset=ISO-8859-1');

ob_start("ob_gzhandler");

Since they are old projects (+4 years), it seems that something has changed in the latest versions of PHP and the opening statement of buffer output can no longer come before the page headers.

  • It can also be something that "rewrites" the headers in the ob_gzhandler depending on the features available on the machine (so I suppose) or really change version. On the machine that the problem occurs, you could inform the PHP version (included if it is x86, x64, etc) :) I just wanted to test, thank you.

  • @Guillhermenascimento PHP Version 5.4.26 in x86_64.

  • Thank you, I tested on similar servers, I did not get the error, as I can not affirm anything, can be really the headerthose who were rewriting the ob_start(...);, when placing the ob_start after fixed their problem +1

Browser other questions tagged

You are not signed in. Login or sign up in order to post.