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
Related
I am trying to push a page to the browser while it is being generated from a PHP script. I have no access to my hosting provider's nginx configuration but they have told me that they use nginx 1.8.1. In my phpinfo() output I can see
output_buffering 0 0
and the same script works as expected on my local PC.
This is my starting script:
<pre>
<?php
for ($i = 0; $i < 100; ++$i) {
print('<b>.</b>');
flush();
usleep(100000); // 0.1 second
}
?>
</pre>
I start getting output immediately on my local PC but I have to wait the full 10 seconds before I see anything when the page is accessed from my hosting.
These are the default response headers:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 12 Apr 2016 12:32:05 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.45
Content-Encoding: gzip
If I add
<?php
header('X-Accel-Buffering: no');
I get
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 12 Apr 2016 12:35:10 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/5.4.45
Content-Encoding: gzip
<?php
header('X-Accel-Buffering: no');
header('Content-Encoding: identity');
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 12 Apr 2016 12:37:11 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 812
Connection: keep-alive
X-Powered-By: PHP/5.4.45
Content-Encoding: identity
Obviously, if the server knows the length of the content, it has waited for the script to finish before starting to send it to the browser.
These are the headers on my local machine:
HTTP/1.1 200 OK
Date: Tue, 12 Apr 2016 12:52:31 GMT
Server: Apache/2.4.7 (Win32) PHP/5.4.45 OpenSSL/1.0.1e
X-Powered-By: PHP/5.4.45
X-Accel-Buffering: no
Content-Encoding: identity
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
The X-Accel-Buffering header gets passed through because I am not running nginx locally.
Are there any other headers I can pass through from PHP to stop nginx from buffering the content? So far I've only found config options, which I don't have access to.
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
calling a .html on my website directly the header will be:
HTTP/1.1 200 OK
Date: Tue, 07 May 2013 14:53:30 GMT
Server: Apache
Last-Modified: Tue, 24 Aug 2012 21:51:42 GMT
ETag: "1431a086-1e01-78e98c5498f1c"
Accept-Ranges: bytes
Content-Length: 7681
Vary: Accept-Encoding
Content-Type: text/html
now the request is forwarded through a php script like
(- the use of the php script here is only to filter some words from the html before delivering it by a regex and to add a footer to every page)
and the header looks like:
HTTP/1.1 200 OK
Date: Tue, 07 May 2013 14:52:50 GMT
Server: Apache
Vary: User-Agent,Accept-Encoding
Content-Type: text/html
Question: How to keep "Last-Modified: ..." and "ETag: ..." ?
Thanks=)
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.
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.