Some of my sites are getting, seemingly without reason, strange errors like these:

[Fri Nov 06 08:29:07.677505 2020] [deflate:error] [pid 23820:tid 140019129566976] [client XXX.XXX.XXX.XXX:XXXXX] AH01386: Zlib error -2 deflating data ((null)), referer: https://www.XXX.XXX/XXX

These errors happen on seemingly random pages, and can be fixed by updating the source code with a comment even. Every change seems to fix this, but the error keeps popping up.

What I've tried

After reading this post https://stackoverflow.com/questions/37952355/zlib-z-stream-error-deflating-data-in-apache-error-log, we have tried migrating the website to another server, updating the zlib library, using a newer server os (debian), using another php version (currently on 7.4). There is nothing in the code that is using (g)zip functionality. There is also nothing in the .htaccess except redirects.

Some info from the phpinfo:

Configure command:
'./configure' '--enable-embed' '--prefix=/usr/local/php74' '--program-suffix=74' '--enable-fpm' '--with-fpm-systemd' '--enable-litespeed' '--with-config-file-scan-dir=/usr/local/php74/lib/php.conf.d' '--with-curl' '--enable-gd' '--with-gettext' '--with-jpeg' '--with-freetype' '--with-kerberos' '--with-openssl' '--with-mhash' '--with-mysql-sock=/var/lib/mysql/mysql.sock' '--with-mysqli=mysqlnd' '--with-pdo-mysql=mysqlnd' '--with-pear' '--with-sodium=/usr/local' '--with-webp' '--with-xsl' '--with-zlib' '--with-zip' '--with-iconv=/usr/local' '--enable-bcmath' '--enable-calendar' '--enable-exif' '--enable-ftp' '--enable-sockets' '--enable-soap' '--enable-mbstring' '--enable-intl' 'PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/local/icu/lib/pkgconfig:/usr/local/lib64/pkgconfig:/usr/local/lib/pkgconfig'

ZLib Support        enabled
Stream Wrapper      compress.zlib://
Stream Filter       zlib.inflate, zlib.deflate
Compiled Version    1.2.7
Linked Version      1.2.7

Directive                       | Local Value       | Master Value
zlib.output_compression         | Off               | Off
zlib.output_compression_level   | -1                | -1
zlib.output_handler             | no value          | no value

When inspecting the response the site gets from the server then te Content-Encoding header is set as gzip, which I think is strange, since (using my limited DevOps knowledge) I think the info given above should indicate to not use compression.

I would share some code, but I can't pinpoint a part of the code that seems to be the problem, and it seems counter productive to show the entire code for a legacy custom CMS.

  • Errors with codes like AH01386 assigned are errors printed by Apache httpd - this is mod_deflate complaining about failing to compress something (an error occurring after whatever is handling/proxying php ran into an error), not the actual error on the php side. Disabling compression in httpd should generally be safe (albeit decreasing performance) and might make error logs about the underlying problem more obvious.
    – anx
    Nov 26, 2020 at 18:00

3 Answers 3


Our website had a similar issue. When viewing the page source retrieved from the server we noticed it was just cut off at some point. We fixed it by adding a flush() call around the cutoff point. Not sure why it was needed and why it worked to be honest.

  • My problem is that any and all changes in the code seem to fix this, but after some time it seems to randomly break again. For a personal website this is workable, but after a few times, this becomes increasingly hard to explain to clients. Nov 24, 2020 at 8:49

For me this was caused when the size of the web page was too large and the php.ini value for output_buffering was exceeded. The buffer is flushed early and you only get a partial web page.

You can set a higher limit for output_buffering or turn output_buffering off to fix this.


Be sure to restart php afterwards. Restarting apache2 didn't load the new php.ini settings for me, needed to restart php separately.


I Had this error today. Disabling PHP notices on top of the page:

<?php error_reporting (E_ALL ^ E_NOTICE); ?>

fixed the problem although I didn't understand why.

  • 1
    That didn't fix the problem, it merely stopped PHP telling you about it.
    – womble
    May 26, 2021 at 9:27
  • Not exactly: it seems that having a lot of notices (not blocking the PHP script) generate the "deflating data" error (which stops executing PHP)
    – Ellery
    Jun 10, 2021 at 8:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .