I have a customer who's got one of these ISPs that implements a cache in order to speed up customer web browsing. This caused him not to download the latest EXE from our NGINX server after an udpate of that EXE from our developers. Is there a way that I can intercept EXE requests from our NGINX and implement a cache-busting header?

NGINX version 1.14.0

Ubuntu Server version 18.04.2

  • Version numbers? – Michael Hampton Mar 1 '19 at 18:57
  • @MichaelHampton edited to show version – ServerChecker Mar 1 '19 at 19:05
  • 1
    Oh sorry, I mean your application should have version numbers in its filename. – Michael Hampton Mar 1 '19 at 19:06
  • @MichaelHampton I want to see if there's an NGINX headers way. That's what this question is about. Our call center has a single URL. It becomes cumbersome if our devs have to contact our cc reps to tell them a new URL every time. – ServerChecker Mar 1 '19 at 19:13

There are no cache busting headers AFAIK.

You can only control cache lifetime, and this is of course, through Cache-Control. Either you instruct clients to have your EXEs cached for this or that time, or not cache at all.

There is no magic header that you send to clients, which have already been instructed to cache an asset for defined time, in order to make them stop using the cached version. They will simply not consult with your server if they currently have a valid cache entry for this resource.

If you can't afford changing URLs which would be the standard cache busting practice, your choices are either very short lived cache or none at all:

location ~ \.exe {
    expires -1;

Which would result in Cache-Control: no-cache.

  • headers are a reccomendation not a guarantee. chaches may ignore headers. Standards may say "MUST NOT", but not everone follows standards: particularly if they can save a buck.

I see two possible solutions:

  • using version numbers in the URL path or the filename of the EXE will be more reliable than cache control headers, because the cache wuill see the new version as a different resource.

  • HTTP is not secure, your customer may be vulnerable to MITM attacks substituting malware. Using HTTPS to serve the files will both block most caching and protect against MITM attacks.

However in instances where the client has trusted a third party to cache their HTTPS traffic (and installed a thrird party root certificate to facilitate that) the First solution: using a unique URL for each version would be needed.

The problem of the changing download URL can be done by having a download page that is opened by means of an HTTP POST request, because nothing caches POST responses.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.