Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm running into a problem with a new production server whereto I'm transferring projects. The HTML output of the PHP applications isn't compressed by the Apache mod_deflate module. Other resources, as stylesheet and javascript files, even html pages, which are served with the same Content-type (text/html) as the PHP output, are compressed!

The projects use the following rules (from HTML5 boilerplate) in the .htaccess:

<IfModule mod_deflate.c>
  # Force deflate for mangled headers developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping/
  <IfModule mod_setenvif.c>
    <IfModule mod_headers.c>
      SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
      RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
    </IfModule>
  </IfModule>

  # HTML, TXT, CSS, JavaScript, JSON, XML, HTC:
  <IfModule filter_module>
    FilterDeclare   COMPRESS
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/html
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/css
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/plain
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/xml
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $text/x-component
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/javascript
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/json
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/xml
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/xhtml+xml
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/rss+xml
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/atom+xml
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/vnd.ms-fontobject
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $image/svg+xml
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $image/x-icon
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $application/x-font-ttf
    FilterProvider  COMPRESS  DEFLATE resp=Content-Type $font/opentype
    FilterChain     COMPRESS
    FilterProtocol  COMPRESS  DEFLATE change=yes;byteranges=no
  </IfModule>
 </IfModule>                                                                                                                                                                 

We have a testing machine that runs the same Apache, OS and PHP version. On that machine the compression works just fine on the PHP output. I've checked and compared Apache and PHP config files, all the same as far as I can tell.

I've tried several manners of outputting the content of the PHP, using output buffering or just plain echoing the content. Same thing, no compression.

Example response headers of a PHP output:

HTTP/1.1 200 OK
Date: Wed, 25 Apr 2012 23:30:59 GMT
Server: Apache
Accept-Ranges: bytes
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: public
Pragma: no-cache
Vary: User-Agent
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

Example of response headers on a css file:

HTTP/1.1 200 OK
Date: Wed, 25 Apr 2012 23:30:59 GMT
Server: Apache
Last-Modified: Mon, 04 Jul 2011 19:12:36 GMT
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Cache-Control: public
Expires: Fri, 25 May 2012 23:30:59 GMT
Content-Length: 714
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/css; charset=utf-8

Does anyone has a clue or experienced the same "problem"?

thanks!

share|improve this question

2 Answers 2

If Apache can't tell how big the returned content is, it will automatically resort to chunked encoding. Depending on how your PHP script is being run (CGI, FastCGI, etc.), Apache may not know the size of the content when it begins returning it to the user. I.e., if you have it outputting content throughout the script, it may write that data to the client's buffer immediately.

The reason it works with static files is because Apache knows the size of them when it begins returning it. This may point to an issue with your Apache/PHP configuration (i.e., it begins writing the moment output is returned from the script), or in how your script itself works.

In other words, this sounds like its a problem with PHP or your Apache/PHP connector, not with mod_deflate.

share|improve this answer
    
Thanks for your answer. I just checked the interface between PHP and Apache (SAPI) on the production server, and it shows 'apache2filter'. On the testing it shows 'apache2handler'. Maybe that has something to do with it? –  FamousInteractive Apr 26 '12 at 0:25
    
On the production server, Apache is compiled with 'mpm_itk', could that interfere? –  FamousInteractive Apr 26 '12 at 0:31
    
For apache2filter/apache2handler, I have no idea. That is part of the PHP SAPI interface, which I'm not particularly familiar with. As far as mpm_itk goes, it shouldn't affect this particular issue. –  Andrew M. Apr 26 '12 at 6:29

Please check if compression of PHP output is enabled. This can be done in the php.ini file or via a run-time directive. Check documentation for more details.

share|improve this answer
1  
I was not looking to let PHP handle the compression. I think it's a better practice to let Apache handle this. This should result in better performance and this way not only the PHP output is compressed. Anyway, still didn't find a solution for the problem. –  FamousInteractive May 8 '12 at 13:58
    
@JensBradler They are total different things, apache is capable to do compression as well, which is a much better, cleaner solution. –  Peter Horvath Aug 26 at 8:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.