Gzip data to be sent to browser in php - php

I want to Gzip data(css,js) being sent to browser in php . I tried gzcompress, gzencode but both made the file unrecognizable by the browser
Data from firebug for home.css
Date Sat, 10 Sep 2011 22:31:59 GMT
Server Apache/2.2.14 (Ubuntu)
X-Powered-By PHP/5.3.2-1ubuntu4.9
Expires Sat, 17 Sep 2011 22:31:59 GMT
Cache-Control public
Pragma no-cache
Etag e35b61f80bbf8e0dd722c50c65ec6da5
Vary Accept-Encoding
Content-Encoding gzip
Content-Length 25163
Keep-Alive timeout=15, max=92
Connection Keep-Alive
Content-Type text/css
EDIT: I even tried below that too didn't work
<?php
if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip'))
ob_start("ob_gzhandler");
else
ob_start();
?>

You need to set the appropriate headers in order for the browser to recognize the file as being compressed.
This really however is a better task for your web server to handle, rather than your code.

try this
<?php
ob_start("ob_gzhandler");
echo file_get_contents("stylesheet.css");
ob_end_flush();
?>
http://php.net/manual/en/function.ob-gzhandler.php
http://www.php.net/manual/en/function.ob-end-flush.php
just tested this with apache, if this isnt working for you you messed something up in your apache config.
headers:
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:180
Content-Type:text/html
Date:Sat, 10 Sep 2011 23:11:18 GMT
Keep-Alive:timeout=5, max=99
Server:Apache/2.2.17 (Win32) mod_ssl/2.2.17 OpenSSL/0.9.8o PHP/5.3.4 mod_perl/2.0.4 Perl/v5.10.1
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.5

Related

Browser not automatically decompressing gz file

I have the same website with the same css file being gzipped and served on two separate servers. Viewing the site on one server, the browser properly decompresses it, and uses the styling. But on the other, the browser does not decompress the file. I thought perhaps this is something to do with the headers, but all the resources I've found seem to think the Content-Type and Content-Encoding are the only two headers that matter for decompressing gzip, and those are the same on both servers. Is there another response header that is incorrect?
The working response headers for the .css.gz file:
HTTP/1.1 200 OK
Cache-Control: public, max-age=604800, must-revalidate
Accept-Ranges: bytes
Content-Type: text/css
Age: 353722
Date: Tue, 07 Apr 2015 21:44:23 GMT
Last-Modified: Tue, 29 Oct 2013 17:44:18 GMT
Expires: Fri, 10 Apr 2015 19:29:01 GMT
Content-Length: 33130
Connection: keep-alive
The response headers for the .css.gz file that don't seem to work:
HTTP/1.1 200 OK
Date: Wed, 08 Apr 2015 15:14:11 GMT
Content-Type: text/css
Last-Modified: Tue, 07 Apr 2015 22:42:25 GMT
Transfer-Encoding: chunked
Connection: close
Content-Encoding: gzip

Chrome totally ignoring Access-Control-Allow-Origin: * header

I am setting this with htaccess. I know it's being set properly because if I set another header:
Header set Access-Control-Allow-Origin2: *
Then chrome does see this. As soon as I remove the 2 however, chrome just completely ignores it. If I make my file a PHP file and put this in it:
<?php header("Access-Control-Allow-Origin: *"); ?>
Then it works.
Here are the response headers as reported by Chrome of the .htaccess method which I need to work and which does not:
HTTP/1.1 304 Not Modified
Date: Sun, 30 Mar 2014 00:13:06 GMT
Server: Apache/2.2.22 (Ubuntu)
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
ETag: "208f3-178a2-4f5c4f119cd34"
Vary: Accept-Encoding
Here are the response headers as reported by Chrome from the PHP method which for some reason does work:
HTTP/1.1 200 OK
Date: Sun, 30 Mar 2014 00:13:09 GMT
Server: Apache/2.2.22 (Ubuntu)
X-Powered-By: PHP/5.3.10-1ubuntu3.10
Access-Control-Allow-Origin: *
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 23
Keep-Alive: timeout=5, max=99
Connection: Keep-Alive
Content-Type: text/html
Again, I know the htaccess is setting the header, even if I go to an online service that checks reponse headers, I see this back:
HTTP/1.1 200 OK
Date: Sun, 30 Mar 2014 00:18:14 GMT
Server: Apache/2.2.22 (Ubuntu)
Last-Modified: Sat, 29 Mar 2014 20:48:34 GMT
ETag: "208f3-178a2-4f5c4f119cd34"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Access-Control-Allow-Origin: *
Content-Length: 33393
Content-Type: application/javascript

php error compression mod_deflate gzip compression

I follow this way compression 1
and
compression 2
how to compression with mod_deflate? I've followed the above link and success to compress but browser can not read compression?
I get an error when I open the css and js files in a browser!
SyntaxError: illegal character
��{{�F�7���"ƫ
and
KÊO©¬NJLÎN/Ê/ÍKÑMÎÏÉ/²RN2H6II­�ó>å¿rŸ—Ï9?ýSúg½/úž;RSŸ‘‡™§çZV†¤ü”Êê¤Ääìô¢üÒ¼Ýäüœü"+å$ƒd“”ÔZ�
Response Headers
Connection Keep-Alive
Content-Encoding gzip
Content-Length 127
Content-Type text/css
Date Wed, 18 Dec 2013 07:15:22 GMT
Expires Fri, 17 Jan 2014 14:15:22 +0700
Keep-Alive timeout=5, max=100
Last-Modified Wed, 18 Dec 2013 13:17:18 +0700
Server Apache/2.2.25 (Win32) PHP/5.3.26
Vary Accept-Encoding
X-Powered-By PHP/5.3.26
anybody please...thanks
It looks like you are compressing the code twice, once with PHP and once with mod_deflate.
Could this be the case?

HTTP Headers difference - load page incrementally

I have an HTML page that shows a progress bar as it steps through a process. It uses flush() to send the data to the browser. I'm trying to get this to work in a Zend process which I'm short circuiting by specifically sending a header, content, then ending the process with an exit command.
The HTML page displays correctly (progress bar steps through being done). The Zend/PHP page only shows the finished page (not the steps). I'm assuming this is a header problem since the method (flush()) is identical.
In Chrome, the header for the HTML page comes up as:
HTTP/1.1 200 OK
Date: Fri, 27 Jul 2012 14:38:07 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8r DAV/2 PHP/5.3.2
X-Powered-By: PHP/5.3.2
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
And the header for the Zend/PHP page comes up as:
HTTP/1.1 200 OK
Date: Fri, 27 Jul 2012 14:44:13 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8r DAV/2 PHP/5.3.2
X-Powered-By: PHP/5.3.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-cache
Pragma: no-cache
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
The only header information I'm specifying in the PHP is:
header('Content-Type: text/html; charset=utf-8');
I'm using this code from this page: http://w3shaman.com/article/php-progress-bar-script
Any help would be appreciated. Thanks.
Call ob_flush() before you call flush() as Zend could have output buffering activated.
Mathieu had the fix. Adding ob_flush() before flush() in the Zend/PHP page fixed the problem. I'm not sure if Zend is activating output buffering as suggested or not.

Google Chrome audit on caching

If I run an audit on my sites with Google Chrome, I get this message in the Leverage browser caching section:
The following resources are missing a
cache expiration. Resources that do
not specify an expiration may not be
cached by browsers:
A list of all the pictures follows. I get a similar notice in Leverage proxy caching:
Consider adding a "Cache-Control:
public" header to the following
resources:
Apart from pictures, I also get a notice about HTML, CSS and JavaScript files:
The following resources are explicitly
non-cacheable. Consider making them
cacheable if possible:
Its funny because I've worked hard to cache all static contents (except for pictures, where I just left Apache's default settings). Firefox does indeed store all these items in cache.
Is there anything I should improve in my HTTP headers?
Here's the complete header set of some items as loaded after removing the browser caché. Pictures use default settings I didn't really check before, the rest should be cachéd for three hours. I can set headers with both .htaccess and PHP.
PNG
HTTP/1.1 200 OK
Date: Sat, 31 Jul 2010 12:46:14 GMT
Server: Apache
Last-Modified: Thu, 18 Mar 2010 21:40:54 GMT
Etag: "c48024-230-4821a15d6c580"
Accept-Ranges: bytes
Content-Length: 560
Keep-Alive: timeout=4
Connection: Keep-Alive
Content-Type: image/png
HTML
HTTP/1.1 200 OK
Date: Sat, 31 Jul 2010 12:46:13 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
Expires: Sat, 31 Jul 2010 15:46:13 GMT
Cache-Control: max-age=10800, s-maxage=10800, must-revalidate, proxy-revalidate
Content-Encoding: gzip
Vary: Accept-Encoding
Last-Modified: Wed, 24 Mar 2010 20:30:36 GMT
Keep-Alive: timeout=4
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html; charset=ISO-8859-15
CSS
HTTP/1.1 200 OK
Date: Sat, 31 Jul 2010 12:48:21 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
Expires: Sat, 31 Jul 2010 15:48:21 GMT
Cache-Control: max-age=10800, s-maxage=10800, must-revalidate, proxy-revalidate
Content-Encoding: gzip
Vary: Accept-Encoding
Last-Modified: Thu, 18 Mar 2010 21:40:12 GMT
Keep-Alive: timeout=4
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/css
JavaScript
HTTP/1.1 200 OK
Date: Sat, 31 Jul 2010 12:48:21 GMT
Server: Apache
X-Powered-By: PHP/5.2.11
Expires: Sat, 31 Jul 2010 15:48:21 GMT
Cache-Control: max-age=10800, s-maxage=10800, must-revalidate, proxy-revalidate
Content-Encoding: gzip
Vary: Accept-Encoding
Last-Modified: Thu, 18 Mar 2010 21:40:12 GMT
Keep-Alive: timeout=4
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/x-javascript
Update
I've tested Jumby's suggestion and set my CSS's expire to 1 year:
Cache-Control:max-age=31536000, s-maxage=31536000, must-revalidate, proxy-revalidate
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:4198
Content-Type:text/css
Date:Mon, 02 Aug 2010 20:48:56 GMT
Expires:Tue, 02 Aug 2011 20:48:56 GMT
Keep-Alive:timeout=5, max=99
Last-Modified:Thu, 18 Mar 2010 20:40:12 GMT
Server:Apache/2.2.14 (Win32) PHP/5.3.1
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.1
However, Chrome still claims "explicitly non-cacheable".
3 hour expiry might not be enough "time" for the yslow/page speed stuff and they might complain about it. I have seen this with static content on my sites with 4 hour expiration & yslow (havent tried with google's stuff).
Most of those want versioned static content with LONG expire times (like 1 year); see here
The problem is the "must-revalidate" part of your cache-control directive. Get rid of that, and you should be good to go.
I just got a similar issue, I discovered the very same setup and code produces a chrome audit warning when trying on my test server at 127.0.0.1, but not on the real server with a real DNS name.

Categories