I am trying to cache images, apparently some aren't caching at all it seems like but some are.
I use Cloudflare, Nginx and Laravel (Laravel Forge) as setup.
Here is the response for the specific image I want to cache.
accept-ranges:bytes
cache-control:public, max-age=14400
cf-cache-status:EXPIRED
cf-ray:3a7de7c45e2b3cd1-CPH
content-length:1572458
content-type:image/jpeg
date:Tue, 03 Oct 2017 06:39:37 GMT
etag:"59d231e8-17fe6a"
expires:Tue, 03 Oct 2017 10:39:37 GMT
last-modified:Mon, 02 Oct 2017 12:32:40 GMT
server:cloudflare-nginx
status:200
vary:Accept-Encoding
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block
It always says cf-cache-status:EXPIRED
The image is quite large as it is a header image for profiles.
I added this to my NGINX config:
location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 365d;
}
But it doesn't work at all..
Related
I have a Rails app on a staging server that is using Cloudfront as a cdn for images in an S3 bucket. The images in the bucket are all jpegs (not gzipped). If I load an image directly from the bucket I can see in its Response Headers that Content Type is set toimage/svg+xml.
The Cloudfront distribution has a single behaviour and compression is switched off:
Compress Objects Automatically: Unchecked
However there is an issue with loading images on the site.
If the requested image is below 1mb the request succeeds, with the Response headers (pertinent headers in bold):
accept-ranges:bytes
age:12058
cache-control:max-age=29030400
content-length:22749
content-type:image/jpeg
date:Fri, 03 Nov 2017 07:35:39 GMT
etag:"5391a06cfff89879e57da305a21e3e4c"
last-modified:Tue, 29 Nov 2016 11:14:53 GMT
server:AmazonS3
status:200
via:1.1 1b61c3f085e80ef7e1cd6e9ac0cdfa77.cloudfront.net (CloudFront)
x-amz-cf-id:1-YfXx6B_px2YlEK7b96chYcC2AfZ_QMd42NpcilQcXhr63gpJ4_uQ==
x-cache:Hit from cloudfront
However if the requested image is above 1mb, the request succeeds, but the image isn't displayed. The headers show that the response encoding is gzip.
age:12712
**content-encoding:gzip**
**content-type:text/html; charset=utf-8**
date:Fri, 03 Nov 2017 07:12:08 GMT
server:Cowboy
status:200 OK
status:200
vary:Accept-Encoding
via:1.1 vegur, 1.1 adc13b6ff82fd04caa2efba65479257c.cloudfront.net (CloudFront)
x-amz-cf-id:_CLNU7iKqnFF1kTNFRJVfrv4iTh8nzol1smRg73p8zESaZo96NZ2gA==
x-cache:Hit from cloudfront
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-request-id:eac71856-51b8-4b11-80eb-95e2b4c5bb37
x-runtime:0.022798
x-xss-protection:1; mode=block
Why is Cloudfront gzipping the images, and why are the gzipped images failing to render to the screen? As far as I understand it, there is no point gzipping images, but they should still be rendered.
I invalidated the distribution and the files were not longer gzipped, displaying correctly.
I'm unsure why the images were not displayed.
Downloading a file directly (without any scripts) from the server, sometimes it fails for slow internet connections.
e,g for any file, each time users can download some percent of the file. And sometimes they can download it completely.
In the cases that download fails, browser doesn't show a "Failed" text. it seems the file has been downloaded completely.
I thought it might be with the keep-alive connection. I use these response headers:
Accept-Ranges:bytes
Cache-Control:max-age=172800
Connection:Keep-Alive
Content-Length:36195412
Content-Type:application/x-rar-compressed
Date:Tue, 28 Jul 2015 07:00:49 GMT
ETag:"a9825a8-2284c54-518bca9ddaaad"
Expires:Thu, 30 Jul 2015 07:00:49 GMT
Keep-Alive:timeout=5
Last-Modified:Wed, 17 Jun 2015 20:37:46 GMT
Server:Apache/2.4.12
Vary:User-Agent
And one more question.You can see in the headers that keep-alive is set like this: keep-alive:timeout=5 there is no max here. so is it default to 0 or something else?
Thanks.
Well, I figured out that it is not related to keep-alive. I and most of our clients were using proxies, it made some problems.
We are adding our custom website font via our CDN. Our CSS code is below. This is in our main.css file which is included in the header of our website.
This works in Safari and Chrome on OSX, but on Windows, it works only in Safari. And maybe IE10. On Firefox it simply doesn't work. And on IE9 etc it works sometimes. (What an irritating browser.)
Some websites suggest that Firefox wants a relative font URL. But we need to use a CDN for our font. How do Google fonts work in Firefox is there is a "same origin" issue?
Our main server is Nginx. The static font files are being served from there, so the Apache suggestion of Allow Origin "*" does not help us much. The CDN in this case is origin-pulled from our website and carries our own headers. So if we need to so send a header via Nginx, we can do that.
THE FONT CSS
#font-face{font-family:'Custom-Sans'
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-light-webfont.eot')
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-light-webfont.eot?#iefix') format('embedded-opentype'),url('http://cache.MYDOMAIN.com/Custom-Sans-light-webfont.woff') format('woff'),url('http://cache.MYDOMAIN.com/Custom-Sans-light-webfont.ttf') format('truetype');font-weight:200;font-style:normal}
#font-face{font-family:'Custom-Sans'
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-thin-webfont.eot')
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-thin-webfont.eot?#iefix') format('embedded-opentype'),url('http://cache.MYDOMAIN.com/Custom-Sans-thin-webfont.woff') format('woff'),url('http://cache.MYDOMAIN.com/Custom-Sans-thin-webfont.ttf') format('truetype');font-weight:100;font-style:normal}
#font-face{font-family:'Custom-Sans'
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-regular-webfont.eot')
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-regular-webfont.eot?#iefix') format('embedded-opentype'),url('http://cache.MYDOMAIN.com/Custom-Sans-regular-webfont.woff') format('woff'),url('http://cache.MYDOMAIN.com/Custom-Sans-regular-webfont.ttf') format('truetype');font-weight:normal;font-style:normal}
#font-face{font-family:'Custom-Sans'
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-semibold-webfont.eot')
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-semibold-webfont.eot?#iefix') format('embedded-opentype'),url('http://cache.MYDOMAIN.com/Custom-Sans-semibold-webfont.woff') format('woff'),url('http://cache.MYDOMAIN.com/Custom-Sans-semibold-webfont.ttf') format('truetype');font-weight:500;font-style:normal}
#font-face{font-family:'Custom-Sans'
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-bold-webfont.eot')
;src:url('http://cache.MYDOMAIN.com/Custom-Sans-bold-webfont.eot?#iefix') format('embedded-opentype'),url('http://cache.MYDOMAIN.com/Custom-Sans-bold-webfont.woff') format('woff'),url('http://cache.MYDOMAIN.com/Custom-Sans-bold-webfont.ttf') format('truetype');font-weight:700;font-style:normal}
And --
THE HEADERS OF A FONT FILE (Served by Nginx)
HTTP/1.1 200 OK
Accept-Ranges: bytes
Access-Control-Allow-Origin: *.MYDOMAIN.com
Cache-Control: max-age=315360000
Content-Type: application/octet-stream
Date: Sun, 10 Aug 2014 15:10:29 GMT
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Last-Modified: Mon, 28 Jul 2014 14:52:44 GMT
Server: Hosting Inc
Vary: Accept-Encoding
Content-Length: 20077
The access control header needs a scheme in addition to the domain:
Access-Control-Allow-Origin: http://*.mydomain.com
It also needs a port if you're using something other than 80.
I'm trying to improve the caching policy for a web site.
I'm implementing an aggressive caching strategy first, for resources that won't change at all, and would like files like jquery-min for example to be downloaded only once, and then be served from browser cache.
I used Apache Mod-Expire module to accomplish this, and it's working pretty well.
However, I'm surprised that when I completely remove my cache-control configuration, Firefox browser does not re-download jquery file : it already gets it from the cache, without any instruction from me. How is Firefox making this kind of decision ? Is it related to the ETag hash ?
Here are the headers I get without my configuration for that particular file :
Accept-Ranges bytes
Connection Keep-Alive
Content-Encoding gzip
Content-Length 27073
Content-Type application/javascript
Date Fri, 23 Aug 2013 09:48:06 GMT
Etag "225f8-13309-4e385823c7b80"
Keep-Alive timeout=15, max=99
Last-Modified Fri, 09 Aug 2013 15:34:22 GMT
Server Apache
Vary Accept-Encoding
Can anyone explain to me what is the browser behavior when there's no Cache-Control policy defined ? is it browser dependant ?
Thank you,
Mathieu.
Despite of doing it in each file type handler, is there any simple way to set default expiry date of all types of file, e.g. json, jpg, html, css, js, etc?
As Nagi said, the connection handler called /handlers/main.c can be used to generate custom expiration HTTP headers.
You can also use content-type handlers which name in the /handlers directory must match the file type (html.c, json.c, jpg.c, etc.).
By default, G-WAN generates HTTP headers which may help proxy servers to do their job:
Date: Thu, 29 Nov 2012 15:00:55 GMT
Last-Modified: Sun, 25 Nov 2012 13:54:46 GMT
ETag: "810c7fa9--50b22326-7ec3"
But a more fine-grained strategy can be used. That could be done in a future version by defining those content-related expirations in content-type handlers.
Proof that a server is a living (customer-driven) creature: