The following is a result of a bug within WebKit's Dev Tools used by Google Chrome and Apple's Safari. I have made a bug report with CrBug, who then identified the regression within WebKit Changeset 116952. I would like to thank @Grumpy and @Matthieu Cormier for their help is tracking this one down. I can't wait for the next build of Chrome Canary :).
I have nginx setup on my server along with PHP-FPM, and during making a new website and trying to make sure that it is as quick as possible I went through Google Chrome's Audit tools. Among some of the errors it gave me this.
Leverage proxy caching (10)
The following publicly cacheable resources contain a Set-Cookie
header. This security vulnerability can cause cookies to be shared
by multiple users.
So what I would like to know is, what do I have to add to the following statement in order for it not to set a Set-Cookie header for this domain. I would then take that information and apply it to css, img, ect subdomains so that it can be properly cached by the browser.
server {
gzip on;
gzip_static on;
listen 80;
server_name img.domain.tld;
root /www/domain/tld;
index index.php index.htm index.html;
location ~* \.(gif|png|jpg|jpeg|svg)$ {
expires 30d;
}
include php_fpm;
}
Follow up for request for more information by Grumpy.
Here is the configuration file that I am for the PHP FPM include, used in the img sub domain.
The PHP-FPM include
location ~ \.php$ {
fastcgi_pass unix:/tmp/php.socket;
fastcgi_param SCRIPT_FILENAME
$document_root$fastcgi_script_name;
include fastcgi_params;
}
As you can see, it should only activate when the location ends with a php file extension.
Funny thing is, I also have a css file that is being reported as having a set-cookie header, and that's being served by the css subdomain that does not have a php-fpm included in it … here is that part of the configuration file.
server {
gzip_static on;
listen 80;
server_name css.domain.tld;
root /www/domain/css;
index index.htm index.html;
location ~* \.(css)$ {
expires 7d;
}
}
The files are …
Leverage proxy caching (5)
The following publicly cacheable resources contain a Set-Cookie
header. This security vulnerability can cause cookies to be shared
by multiple users.
- style.css (served by css.domain.tld)
- 2009EMSWeekLogoSmall.jpg (served by domain.tld)
- EMS%20FOUR.jpg (served by domain.tld)
- get_adobe_reader.png (served by img.domain.tld)
- dhs-ntas-badge-small.jpg (served by dhs.gov)
the domain.tld server configuration looks like this.
server {
gzip on;
gzip_static on;
listen 80;
server_name .domain.tld;
root /www/domain/www;
index index.php index.htm index.html;
location ~* \.(htm|html|ico|icns|hqx|gif|png|svg|jpg|jpeg|svg)$ {
expires 1d;
}
include php_fpm;
}
Best Answer
Identifying a resource to be cached is a non-default behavior. So, whatever is causing this notification by Chrome is an object you specified to be cached.
The directive to cache (public in this case) can be set in 2 ways.
Per your above nginx configuration, and ignoring the entire
include php_fpm;
, there's nothing which would suggest #1 unless your images (gif, jpg, png) are somehow being executed.It's also possible that PHP has such cache directive. In such case, it's something you really should be fixing from the core rather than trying to do a patch up job.
But with these two cases, you can also enter an odd scenario. If your image is not found, it will attempt to find a 404 page. And if 404 is an executable (php) either directly or indirectly, it can then carry a set cookie command. This would be a poor behavior if 404 directive is also tells it to be cached. So, be sure to check that as well. The same also obviously applies to any other error codes.
This is about all I can guess given the current information. You may want to follow up with additional information as to which exact item is causing the Chrome to give such message, if there are any errors found as well as full configuration of nginx and/or php-fpm.
I tried looking at the full HTTP headers to see if there's any indication of cookies or any custom information being passed around.
Sample response header from OP's site causing warnings.
Sample response header from my site that doesn't cause warnings.
Can you spot the difference? I can't!
I would label this as a bug with Chrome Audit.