I have deployed a wordpress for linux app on an azure. It is working fine but I cannot get the Cache-Control header to set a max-age.
I am using the w3 total cache plugin and have set the options "Set expires header" with a value of 31536000 and "Set Cache Control policy" to Cache with max-age for css,js and media.
I can then see all the correct changes made in the htaccess file.
But the max-age value never gets set in the response Cache-Control header
I ran a phpinfo() and results are as follows
Apache Version Apache/2.4.25 (Unix) OpenSSL/1.0.2g PHP/7.1.2
Apache API Version 20120211
Server Administrator [no address given]
Hostname:Port 172.18.0.5:80
User/Group www-data(33)/33
Max Requests Per Child: 0 - Keep Alive: on - Max Per Connection: 100
Timeouts Connection: 60 - Keep-Alive: 5
Virtual Server Yes
Server Root /usr/local/httpd
Loaded Modules core mod_so http_core prefork mod_authn_file mod_authn_core mod_authz_host mod_authz_groupfile mod_authz_user mod_authz_core mod_access_compat mod_auth_basic mod_reqtimeout mod_filter mod_mime mod_log_config mod_env mod_headers mod_setenvif mod_version mod_ssl mod_unixd mod_status mod_autoindex mod_dir mod_alias mod_rewrite mod_php7
In the loaded modules there is no mod_expires listed which would probably indicate this may be the problem.
BUT how do I install this..?
Related
I am currently running Magento 2.1.14 and have enable gzip per the Magento documentation as well as the other well visited posts on this site. I have also doubled checked with my hosting provider that Mod_deflate is enabled on the server side.
In addition, I have a copy of my site on my local machine with same htaccess files as what resides on our live server.
On my local machine, simply enabling the apache module and then adding the htaccess code in the main htaccess file of the public_html directory works. All requests on my local site show headers that contain “Content Encoding: gzip”.
However, when live using https on our server, the gzip encoding seems to stop at the pub directory. NO content coming from the pub directory (pub/static and pub/media) shows and gzip encoding. The files on my local machine and live server are the same. According to my hosting provider, gzipped is enabled on their side and they believe that is has to do with one of the htaccess files in my file tree that is stopping the gzip encoding from happening.
I did a small test recommended by our hosting provider as well, and tried to set up an extra directory in the public_html directory on both my local machine and the live server to test if the gzip encoding would work. On my local machine, I can visit the directory and the file in it shows gzip compression, but on my live server, when adding the file to my public_html directory and attempting to visit it through the browser, Magento throws a 404 error!
Does anyone out there have any idea why gzip would not waterfall through my file tree and properly gzip the js, minified js, css and minified css files that are located in the pub folder?
After days of debugging it turns out that on my live server, the RequestHeader for Set-Encoding was being stripped. This was not happening on my Apache setup on my local machine. My web host still has not give me an explanation why this was happening, nor do I know if it has to do with the htaccess file in the pub/static directory, but adding the RequestHeader set below:
<IfModule mod_headers.c>
Header set X-UA-Compatible "IE=edge"
Header set Connection keep-alive
#THE LINE BELOW THIS COMMENT
RequestHeader set Accept-Encoding "gzip, deflate, br"
<FilesMatch "\.(appcache|atom|bbaw|bmp|crx|css|cur|eot|f4[abpv]|flv|geojson|gif|htc|ico|jpe?g|js|json(ld)?|m4[av]|manifest|map|mp4|oex|og[agv]|opus|otf|pdf|png|rdf|rss|safariextz|svgz?|swf|topojson|tt[cf]|txt|vcard|vcf|vtt|webapp|web[mp]|webmanifest|woff2?|xloc|xml|xpi)$">
Header unset X-UA-Compatible
</FilesMatch>
to the htaccess file in the root of my magento site fixed the issue with the compression.
If this is a server issue, I would like someone to comment below on what I might bring up with my webhost to address this. Otherwise, I'm going to submit an issue to the Magento github.
Very strange issue,
deflate mode included in .htaccess of pub/static
bat not for all file types,
javascript files not added to setting
so,
just edit pub/static/.htaccess
and edit row with start - AddOutputFilterByType DEFLATE
and add content type -
text/javascript application/javascript application/x-javascript application/json image/svg+xml
now, all static content will with gzip.
Strange, why was missed this,
maybe for other features ?
In httpd.conf (Unix / Mac OS Sierra) I've got "Header set X-Frame-Options SAMEORIGIN"
I'd like to override that for a specific directory to
X-Frame-Options ALLOW-FROM SpecificDomain.com
Goal is to allow iframe acess to that directory but no others.
I tried adding the ALLOW-FROM line to an .htaccess file in the target directory but no luck. iFrame is denied, browser console saying "X-Frame-Options" are set to "SAMEORIGIN"
There are compatibility issues with some browsers with the Allow-From parameter for X-Frame-Options response header, chances are you are dealing with a browser which does not support it.
Ideally try this command to see the headers output and make sure the setting you made is being used:
curl -I http://yourserver.example.com/exceptionpath/
If it is, instead of setting that other header you may also want to unset that header in that directory to avoid compatibility issues with that parameter:
Header unset X-Frame-Options
or if the above is not being applied:
Header always unset X-Frame-Options
Sidenote: If you are the admin of the site you don't need to use .htaccess if you have access to main configuration files, set in the appropiate Directory entry instead. Disable .htaccess files altogether with AllowOverride none. Configurations will be simpler and you will gain a bit of performance by not forcing httpd to constantly read that file several times with each hit.
I am using W3 Total Cache with Amazon cloudfront. I have in my htaccess file:
# BEGIN W3TC CDN
<FilesMatch "\.(ttf|ttc|otf|eot|woff|font.css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
# END W3TC CDN
But still getting error:
Font from origin 'https://example.cloudfront.net' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://www.example.com' is therefore not allowed access.
Why is this happening?
Found the solution in this link: https://www.naschenweng.info/2014/09/23/wordpress-w3-total-cache-cloudfront-font-cors-issue/.
You need to change the CloudFront distribution's behaviors settings:
Change “Forward Headers” from “None” to “Whitelist”
Add “Origin” to the “Whitelist Headers”
Make sure that “Use Origin Cache Headers” is checked
Then invalidate the cached fonts.
Wrestling with this for days, and think I finally fixed it. Here are some things to check:
The webserver config should add the proper header. Apache syntax is listed in the question. Here's Nginx syntax that I used:
location ~* \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin '*';
}
Within W3TC > Performance > CDN > Custom File List, I added the following to upload the actual font files:
{plugins_dir}/*.ttf
{plugins_dir}/*.woff
While you're there, set the Theme file types to upload to the following. Per #Yao's link, the default separators are inconsistent (should all be semicolons, not commas)
*.css;*.js;*.gif;*.png;*.jpg;*.ico;*.ttf;*.otf;*.woff;*.less
In S3 > Permissions > CORS Configuration, change the default
<AllowedHeader>Authorization</AllowedHeader>
to:
<AllowedHeader>*</AllowedHeader>
You should start seeing the necessary Access-Control-Allow-Origin header in the response.
In CloudFront > Distribution > Behaviors, make the following changes:
Change Allowed HTTP Methods to GET, HEAD, OPTIONS (you need OPTIONS)
Change Forward Headers to Whitelist
Under Whitelist Headers, Add >> Origin
To test:
curl -I -s -X GET -H "Origin: www.example.com" https://abcdefg543210.cloudfront.net/wp-content/path/to/foo.ttf
This should give you back the following header:
Access-Control-Allow-Origin: *
X-Cache: Miss from cloudfront
I found this blog post to be pretty helpful:
http://blog.celingest.com/en/2014/10/02/tutorial-using-cors-with-cloudfront-and-s3/
basicly It's because the font isn't set to be shared outside of the domain that you are on, so you can just use it as a resourse for, in this case, https://example.cloudfront.net
This can be changed in the webserver settings though.
The problem may not always be with the origin settings on Nginx or Apache at your web server end.
You will also need to enable CORS on your S3 AWS account for this to work correctly.
I have enabled the keep-alive option in my WHM
but I still get "close" when I have checked by many tools like this
http://www.giftofspeed.com/check-keep-alive/
http://gtmetrix.com/
And I have added the code in .htaccess file but the option is still not working
<ifModule mod_headers.c>
Header set Connection keep-alive
</ifModule>
And when I create php file to print "HTTP_CONNECTION"
I get "close"
Thanks a lot
You have to reconfigure apache to have it handle keepalive.
The most relevant settings are:
KeepAlive On
Keepalivetimeout 5
MaxKeepaliveRequests 100
See the documentation here:
http://httpd.apache.org/docs/current/en/mod/core.html#keepalive
And a discussion which points to some caveats here:
https://abdussamad.com/archives/169-Apache-optimization:-KeepAlive-On-or-Off.html
In my htaccess file there is this :
<FilesMatch "\.(js|css|pdf|txt)$">
Header set Cache-Control "max-age=7257608"
</FilesMatch>
Now, if I wanted to alter a css type file. the css will change if I refreshed the page. Other users still get the old css file because of the cache. what can I do on my side to let the users browsers recognize there is a change in the css file?
Generally rather than setting a cache age in the .htaccess, make sure you're configured to use if-modified-since which is documented in the Apache Caching Guide, using the mod_cache extension:
Generally, it's as simple as this, with exceptions written for secured resources:
LoadModule mem_cache_module modules/mod_mem_cache.so
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 4096
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 2048
</IfModule>