I have website setup to serve static files via CDN. I'm using cloudfront CDN. When i open my website on mobile using UC Browser. it only loads the HTML page and do not accepts the files(images,.js,.css, etc..) delivered by CDN.
However When I turn of CDN and serve files directly then my sites work without any problem. The problem occurs when ad-block mode is On in UC Browser.
about 80% visitors of my site uses UC browser and I don't want to turn off CDN. Also I've seen some websites that uses CDN and works fine in UC browser with ad-block mode turned On.
here are the headers returned by CDN for js file
age: 237446
cache-control: public, max-age=2592000
content-encoding: gzip
content-type: application/javascript
date: Mon, 24 Sep 2018 10:51:26 GMT
last-modified: Sat, 15 Sep 2018 08:56:57 GMT
server: Apache/2.4.18 (Ubuntu)
status: 200
vary: Accept-Encoding
via: 1.1 b5fbf0f0a39109b04a248c9bb51b5d6a.cloudfront.net (CloudFront)
x-amz-cf-id: IoyQ_74Qgo9nqBRJN0YHkTZk-atMfRscw50y27LxPiMuUG0VeQUxHA==
x-cache: Hit from cloudfront`
Related
I have a CloudFront distribution that blocks the font download in Chrome (desktop version) with the fallowing error:
Font from origin 'https://....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://example.com' is therefore not allowed
access.
Where should I set this Access-Control-Allow-Origin header?
I tried adding the header in the "Origin" section of the could distribution but it does not produce any effect.
EDIT #1:
Nginx configuration on origin has the fallowing directive:
location ~ \.(eot|ttf|woff|woff2)$ {
add_header Access-Control-Allow-Origin *;
}
which on this test curl -I https://example.com/skin/frontend/smartwave/default/megamenu/css/fonts/fontawesome-webfont.woff
Retuns the fallowing response:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 02 Feb 2016 17:53:39 GMT
Content-Type: application/font-woff
Content-Length: 44432
Last-Modified: Wed, 13 May 2015 15:58:11 GMT
Connection: keep-alive
ETag: "55537493-ad90"
Pragma: public
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
Accept-Ranges: bytes
From what I see here this header Access-Control-Allow-Origin is missing.
Also I whitelisted the header on CloudFront so that it will not block it:
That was hard to trace as the rules for headers were set in 2 different locations and not in one.
Fixing the correct header for the correct type of file did the job, but you have to consider the fact that in some locations trying to overwrite the NGINX rules does not work. It will only consider the first rule.
A comprehensive description of headers can be found here https://stackoverflow.com/a/10636765/1168944
Test on this url
http://getapple.net/phpbb/banners.js
It return 304, File not modified.
I have once enable plugin "mod_expires" and set up js to cache for 1 month.
But now i want to reset the rules. I try to comment this line
ExpiresByType application/javascript "access 1 month"
and then restart apache.
But the file still load from cache. (Response Header return 304 in Chrome Browser)
But after i run this
curl -I http://getapple.net/phpbb/banners.js
in command line, the result are
HTTP/1.1 200 OK
Date: Sun, 10 May 2015 14:51:59 GMT
Server: Apache/2.4.7 (Ubuntu)
Last-Modified: Sun, 10 May 2015 14:34:14 GMT
ETag: "9dd2-515bb27cf250a"
Accept-Ranges: bytes
Content-Length: 40402
Vary: Accept-Encoding
Content-Type: application/javascript
I don't know what i did wrong. Please suggest how to get the updated version of my file via url.
Thanks a lot.
When you send Expires header to browser, it will cache your response and only check for newer version after the expiration date has passed. Since browser won't check for newer version, changing your server settings won't affect browser's cached data. If you made some mistake in your script or there is an update, you can use query string to force browsers to ask for your script.
Assume this is your current script:
<script src="http://getapple.net/phpbb/banners.js" ></script>
What you need to do:
<script src="http://getapple.net/phpbb/banners.js?v=20150510" ></script>
Since URL is not the same, browser will ask for the one with query string and your new settings will be applied!
i am using Apache as backend server and nginx as frontend server. I need to make PDF files downloadable (at this moment they are opening in a browser window).
Here's a link:
link
Here's what i have tried so far in my .htaccess file:
<FilesMatch "\.(pdf)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
Didn't work, just opens the file in a browser.
AddType application/force-download pdf
Didn't work.
AddType application/octet-stream .pdf
Didn't work.
UPDATE
Tried: wget --server-response -O /dev/null http://domain.com/files/teltomat.pdf
And got response:
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 24 Sep 2014 17:40:54 GMT
Content-Type: application/pdf
Content-Length: 3116445
Last-Modified: Wed, 24 Sep 2014 13:28:07 GMT
Connection: keep-alive
Keep-Alive: timeout=60
ETag: "5422c6e7-2f8d9d"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes
Length: 3116445 (3,0M) [application/pdf]
Saving to: ‘/dev/null’
You could try the HTML5 solution of adding a "download" instead of "target":
link
As it looks like the server's end is doing the right thing (by making the disposition "attachment") but maybe the browser is deciding on its own that it can handle PDF's inline and opens a new window instead.
I have setup apache2 with django and mod_wsgi in Debian Wheezy. I enabled mod_mem_cache with this configuration:
<IfModule mod_mem_cache.c>
CacheEnable mem /
MCacheSize 400000
MCacheMaxObjectCount 100
MCacheMinObjectSize 1
MCacheMaxObjectSize 500000
CacheIgnoreNoLastMod On
CacheIgnoreHeaders Set-Cookie
</IfModule>
based on the fact that MCacheMaxStreamingBuffer is the smaller of 100000 or MCacheMaxObjectSize as stated in the docs.
When I try hitting a page with size 3.3KB I get these response headers in firebug:
Connection Keep-Alive
Content-Encoding gzip
Content-Type text/html; charset=utf-8
Date Wed, 27 Aug 2014 14:47:39 GMT
Keep-Alive timeout=5, max=100
Server Apache/2.2.22 (Debian)
Transfer-Encoding chunked
Vary Cookie,Accept-Encoding
and the page isn't served from cache. In the page source there is however the correct header 'Cache-Control: max-age=300,must-revalidate' but doesn't show up in firebug.
In apache log I only see correctly:
[info] mem_cache: Cached url: https://83.212.**.**/?
With another test page that I created outside of django that doesn't have chunked encoding as a header, caching works fine. Why is the page not served from cache? Has anyone seen something similar?
I am having trouble with caching on a website that I'm working on updating. Many of the resources I've updated (javascript, css, and image files) appear to be cached locally by browsers. What I can't understand is why, or how to resolve this short of renaming everything I've edited (which isn't a very attractive solution).
The server is generating the following in http headers.
Date Fri, 06 Jan 2012 00:09:32 GMT
Server Apache/2.2.16 (Amazon)
X-Powered-By PHP/5.3.5
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Content-Length 3636
Connection close
Content-Type text/html; charset=UTF-8
Based on what I understand from cache control directives, resources shouldn't be cached. Despite this, I'm getting images, css, and javascript files that are not updating after I upload changes.
Any ideas on how I can resolve this or best practices?
After making little headway on this I decided to place all of my cache-able resources in versioned folders (ie. css-1.2.1, js-1.2.1, etc). Any time I update the site I just increment my version numbers (I'm keeping all version numbers synchronized). This is suboptimal in terms of cache optimization, but it means I don't have to track individual version numbers for every resource. Given I'm not updating the site every four hours, it will just mean users have to download a fresh resource set whenever I update the site.