Primary domain cache problem

Support
1

Hi,

I am deploying a simple Vue app. Everything works fine with netlify domain xxx.netlify.com but it is not working with my primary domain mydomain.com

The problem is when you load the page, the main js file (created in the build) is not there. So, comparing both files in both cases:

xxx.netlify.com/js/app.a23a34e2.js —> works fine

mydomain.com/js/app.bb389afb.js —> returns 404 error HTML page

I realized the names of the files are different, it makes no sense because they should work against the same build.

Also, if I try with my domain and the js file name from the netlify domain, it works fine:

mydomain.com/js/app.a23a34e2.js

I have tried to run a “clear cache and deploy site” but the problem is still there.

The build configuration seems ok:
Build command: npm run build
Publish directory: dist

So, it seems like a bug or am I doing something wrong?

Thanks!

2

I don’t know if this might be part of your issue, but Netlify’s CDN works best with FQDN, so www.mydomain.com is going to be properly cached, while mydomain.com will not be.

You might try setting www.mydomain.com as your primary domain in the Netlify dashboard under Settings → Domain Management → Domains.

1 Like
3

Hi, @pedromartin, and welcome to our Netlify community site.

What are the actual URLs which do and do not work? If you would prefer to send this information to us privately you can send that to one of our support team in a private message (PM).

Please note, sending a PM means the rest of the support team cannot see the message and will likely result is a slower response than a public answer.

4

Hi, thanks for both responses.

These are the URLs:
https://pedromartin.pro —> Pedro Martín - Expertos en madera de pino
https://agitated-ptolemy-7426d5.netlify.com —> Pedro Martín - Expertos en madera de pino

And as I said, if I try Pedro Martín - Expertos en madera de pino, it works.

Thank you

5

Hi, @pedromartin, I’m seeing that this site has a single page application (SPA) redirect rule configured for it.

For files which don’t exist there is a 200 redirect to the path /index.html.

This file (at the path /js/app.a23a34e2.js) exists currently. Both these URLs work for me and return the same javascript:

However, this file does not exist in the current deploy: /js/app.bb389afb.js.

This means both of the URLs below also return 200 response but serve /index.html instead:

My best guess is that this file existed in a previous deploy and it used to work but doesn’t anymore because a new deploy has been published without it.

If there are other questions about this, please let us know.

6

Yes, it is basically what I said previously and the problem. So let me be more clear.

The problem: https://agitated-ptolemy-7426d5.netlify.com is running properly against the last build (it is configured to make a build in every push to master) but https://pedromartin.pro is not using the last one (at least some files seem to be cached)

My question: why https://agitated-ptolemy-7426d5.netlify.com is returning the right js file and the https://pedromartin.pro is using a previous one? shouldn’t they be exactly the same?

My guess: some cache problem on your side or a configuration problem (in netlify) on my side.

Thank you!

7

Hi, @pedromartin, I’m seeing this site using a service worker. This is the most likely reason for this behavior. You’ll need to uninstall the service worker locally to resolve that issue.

There is more information about this at the topic link below:

If you believe that Netlify is sending the wrong version, we need to be able to track the HTTP response with this issue. The simplest way to do this is to send us the x-nf-request-id header with every HTTP response.

There more information about this header here:

If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:

  • the complete URL requested
  • the IP address for the system making the request
  • the IP address for the CDN node that responded
  • the day of the request
  • the time of the request
  • the timezone the time is in

Again, I don’t think x-nf-request-id header will be required though as I’m 99.9% certain this is the service worker doing this. (I’m 100% certain there is a service worker.) If there are other questions about this, please let us know.

1 Like