I have a web application that offers file downloading functionality. I would like to enable browser cache (Cache-Control header) so that subsequent downloads of a file come from the browser cache, instead of generating a new HTTP Request to the server.
HTTP Request:
http://localhost:9080/webapp/action/content/somefile.exe
HTTP Response:
Cache-Control:max-age=600
Content-Disposition:inline;filename="somefile.exe"
Content-Length:20952624
Content-Type:application/x-msdownload
Date:Thu, 22 Oct 2015 10:46:17 GMT
Last-Modified:Thu, 22 Oct 2015 10:44:49 GMT
X-Powered-By:Servlet/3.1
However, despite the Cache-Control header, the browser (latest releases from Firefox & Chrome) always asks the server for the file. Any idea why?
Related
Site running Google Cloud CDN -
According to numerous test is not Caching webp images - potentially all images.
This was corroborated with GTMetrix.
Initially, I used the Cloud CDN configuration of "Cache Static Content".
and later upgraded to "Use origin settings based on cache-control headers"
Current Cache Settings:
I am still seeing images, particularly webp not being cached by CDN.
I have also updated the .htaccess file to increase the TTL for webp.
Htaccess images TTL
How can I get these images cached properly in cloud CDN?
Just adding to elving's answer - the report is wrong - your site is using CDN for images too.
I've fallowed official documentation on troubleshooting GCP's CDN.
Just run curl -s -D - -o /dev/null https://mydoginsurance.com.au/images/banner.webp and you should get:
HTTP/2 200
server: nginx
date: Thu, 25 Feb 2021 12:26:01 GMT
content-type: image/webp
content-length: 130564
last-modified: Fri, 16 Oct 2020 10:12:50 GMT
etag: "5f897222-1fe04"
x-powered-by: PleskLin
accept-ranges: bytes
via: 1.1 google
cache-control: max-age=86400,public
alt-svc: clear
and when I ran it again a few minutes later:
HTTP/2 200
server: nginx
date: Thu, 25 Feb 2021 12:26:01 GMT
content-type: image/webp
content-length: 130564
last-modified: Fri, 16 Oct 2020 10:12:50 GMT
etag: "5f897222-1fe04"
x-powered-by: PleskLin
accept-ranges: bytes
via: 1.1 google
age: 223
cache-control: max-age=86400,public
alt-svc: clear
Third last line is age: 223 which means that this reponse was served from cache created 223 seconds ago;
The last response in this example includes an Age header. Cloud CDN adds an Age header to responses that it serves from cache. Here, the header indicates that the response was successfully served from cache by using a cache entry that was created two seconds ago.
That GTmetrix report is simply wrong. They apparently don't correctly detect use of Cloud CDN. I see cache hits from Cloud CDN for images such as /images/banner.webp.
There's information on troubleshooting cache misses at https://cloud.google.com/cdn/docs/troubleshooting-steps#responses-not-cached that you can use to double check.
Context
My github pages are not refreshing. After diagnosing my conclusion is it's a server side caching effect.
What I did + diagnostic results
The site is working OK.
I made a change in index.html in my local
repo, then commit and push
I completely cleared my browser cache (btw also using cache clear plugins, and Chrome dev tools set not using cache)
Reloaded the page, with ctrl+f5 and ctrl+R (change is not applied)
Checked using github.com read index.html, the change is there, committed.
Monitored the traffic with Fiddler. The request for index.html sent, full response received, the content is the old NOT changed.
Examined the response header with Fiddler, says: (see header exhibit)
Reverse diagnostic
I've issued a request with a usual trick typeing: index.html?v001orAnythingYouWant and I got the new version of the page
Problem
Problem solved one can say, but it is not true. When I refresh images, css, js still this effect will prevent me to see the new result.
Question
How can I configure or overcome this server side caching, of course only for development/testing time?
Response header exhibit
HTTP/1.1 200 OK
Server: GitHub.com
Content-Type: text/html; charset=utf-8
Last-Modified: Fri, 06 May 2016 12:24:29 GMT
Access-Control-Allow-Origin: *
Expires: Fri, 06 May 2016 12:45:44 GMT
Cache-Control: max-age=600
X-GitHub-Request-Id: B91F111E:5AA6:47804:572C8F9F
Content-Length: 43752
Accept-Ranges: bytes
Date: Fri, 06 May 2016 12:35:57 GMT
Via: 1.1 varnish
Age: 13
Connection: keep-alive
X-Served-By: cache-fra1238-FRA
X-Cache: HIT
X-Cache-Hits: 1
Vary: Accept-Encoding
X-Fastly-Request-ID: 1758f53052edbfb40a0044407d53d5654ad1e983
If a resource (index.html) is already cached in the client, for example using response header:
"Cache-Control": "max-age=0, must-revalidate, proxy-revalidate"
How can I prevent tomcat to respond with a 304 Not Modifiedin the next request to the server? I would like to force the server to respond with 200 instead of 304 no matter what.
I tried to set
httpResp.setHeader("Cache-Control", "no-cache, no-store, must-revalidate, proxy-revalidate");
httpResp.setHeader("Pragma", "no-cache");
httpResp.setHeader("Expires", "0");
but it only works in the SECOND request. The first request still gets 304.
I tried to override the if-modified-since header using HttpServletRequestWrapper with values in the past such as Mon, 06 Dec 2010 01:34:46 GMT with no luck - client still gets 304 responses although the file was modified in 2015.
Is there any way I can prevent 304 responses? maybe via tomcat configuration?
Not sure if this will help but you could try the following -
Delete the browser cache to start from scratch and test whether this works or not
Adapted from another ServerFault question -
https://serverfault.com/questions/40205/how-do-i-disable-tomcat-caching-im-having-weird-static-file-problems?answertab=votes#tab-top
You might have to delete the application cache folder in /work/Catalina/localhost after changing the cachingAllowed flag.
Configuration can be introduced in server.xml as
<Context className="org.apache.catalina.core.StandardContext"
cachingAllowed="false"
charsetMapperClass="org.apache.catalina.util.CharsetMapper"
cookies="true"
reloadable="false"
wrapperClass="org.apache.catalina.core.StandardWrapper">
</Context>
When downloading a file from an IIS6-hosted ASP.NET MVC 3 application, the content-length header is not set for .exe files.
MIME-types appear to be correctly set. (.exe is application/octet-stream). Static content compression is disabled.
As far as I can tell, this problem is specific to .exe files. .zip works fine.
Suggestions?
Update
Here are the headers that are being sent:
Accept-Ranges:bytes
Cache-Control:max-age=86400
Compression-Control:whitespace
Content-Encoding:gzip
Content-Location:http://...../someFile.exe
Content-Type:application/octet-stream
Date:Wed, 28 Aug 2013 15:45:52 GMT
ETag:"5397aeeb6e4ace1:0"
Last-Modified:Mon, 06 May 2013 15:32:30 GMT
Transfer-Encoding:chunked
Vary:Accept-Encoding
Turned out we had an ISAPI filter running that was stripping out some headers, including this one.
Disabling the filter fixed the problem.
We have recently moved to a new web server (from IIS6 to IIS7.5) and I'm having some trouble updating our VSTO word addin.
Our app checks for updates manually when logging in and if a newer version has been found updates like this (let me know if there is a better way to do this - I've tried ApplicationDeployment.Update() but had no luck with it either!):
WebBrowser browser = new WebBrowser();
browser.Visible = false;
Uri setupLocation = new Uri("https://updatelocation.com/setup.exe");
browser.Url = setupLocation;
This used to launch the setup and update the app and when the user restarted word they would have the new version installed. Since the server move the update no longer happens. No exceptions are thrown. Browsing to the URL launches the updater as expected. What would I need to change to get this to work?
Note I have the following MIME types setup on the folder in IIS:
.application
application/x-ms-application
.manifest
application/x-ms-manifest
.deploy
application/octet-stream
.msu
application/octet-stream
.msp
application/octet-stream
.exe
application/octet-stream
Edit
OK I've had a look in fiddler and its returning a body size of -1:
If I enter the same URL in IE you can see that the setup.exe is launched without problems.
This is what fiddler displays in the raw view when accessing from word:
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Last-Modified: Tue, 27 Sep 2011 15:07:42 GMT
Accept-Ranges: bytes
ETag: "9bd0c334277dcc1:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Mon, 14 Nov 2011 07:42:18 GMT
Content-Length: 735608
MZ��������������������#������������������������������������������ �!�L�!This program cannot be run in DOS mode. $�������
*** FIDDLER: RawDisplay truncated at 128 characters. Right-click to disable truncation. ***
Have you tried a tool like (for instance) fiddler2 to see what http traffic is actually created?
Does the client make a server call? What does the server actually return?
Then:
Make the calls from within word (which isn't working)
Make the calls by hand (which is working)
Compare both the request and response packages from those calls to spot the differences