Netlify caches old redirects and breaks sites

I have a static website, multiple pages, not an SPA.

Here is my goal:

To achieve this I created this redirect

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 301
  force = false

But it breaks everything, and the worst part it does so at random. For example deploy previews work perfectly but when deployed to the site they break everything.

So now what happens in production:

  1. https://appfleet.com/ redirects to Deploy docker containers to the edge - Global container clusters close to your users -WRONG
  2. appfleet edge hosting pricing redirects to Deploy docker containers to the edge - Global container clusters close to your users WRONG
  3. Command line tests with curl return completely random results

For root domain:

]# curl -I https://appfleet.com
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Sun, 04 Oct 2020 10:18:48 GMT
etag: "e03f5e68baefa4330994d1936b90478f-ssl"
strict-transport-security: max-age=31536000
age: 1291
content-length: 59164
server: Netlify
cache-control: public,max-age=10
x-nf-request-id: e6d43984-063e-4286-9e96-cfd6b45dd3a3-44735302

# curl -I https://appfleet.com
HTTP/2 301
content-type: text/plain
location: /index.html
date: Sun, 04 Oct 2020 10:40:08 GMT
content-length: 27
age: 254
server: Netlify
x-nf-request-id: 2693535a-0d91-4da6-b810-d05ab136aff5-42900938

For /

# curl -I https://appfleet.com/
HTTP/2 301
content-type: text/plain
location: /index.html
date: Sun, 04 Oct 2020 10:36:42 GMT
content-length: 27
age: 479
server: Netlify
x-nf-request-id: dea186d3-86fd-4ebe-a68f-c2334d393125-30660549

# curl -I https://appfleet.com/
HTTP/2 200
content-type: text/html; charset=UTF-8
date: Sun, 04 Oct 2020 10:19:41 GMT
etag: "e03f5e68baefa4330994d1936b90478f-ssl"
strict-transport-security: max-age=31536000
age: 1502
content-length: 59164
server: Netlify
cache-control: public,max-age=10
x-nf-request-id: 97af8e4d-1c06-4154-94ec-ebbd5ddad31f-48366184

for /pricing

# curl -I https://appfleet.com/pricing
HTTP/2 200
content-length: 0
content-type: text/html; charset=UTF-8
date: Sun, 04 Oct 2020 10:36:05 GMT
etag: "6134d66703c750d1e472a4fb668459cb-ssl"
strict-transport-security: max-age=31536000
age: 0
server: Netlify
cache-control: public,max-age=10
x-nf-request-id: a674656e-4a76-4b05-ba9e-c36c12624f87-45171490

# curl -I https://appfleet.com/pricing
HTTP/2 301
content-type: text/plain
location: /index.html
date: Sun, 04 Oct 2020 10:45:24 GMT
content-length: 27
age: 0
server: Netlify
x-nf-request-id: b37c5d48-8de7-4a11-a178-49f9baa53fe1-3707107

Because of the complete randomness I can’t test any possible solutions :frowning:

I provided all the info I could but since this is breaking our production website for now I removed the new redirect rule in hopes of fixing it. But all the request IDs are there for you to check

You specified the wrong redirect rule. You just need to:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 404

That status should be changed from 301 to 404 because 301 means permanent redirect. It’s redirecting all pages of your website to index.html.

I want it to redirect all non existing pages to /. I dont want it to reply with a 404 http status.

Well, all non-existing pages anyways reply with a 404 status. But, I think you misunderstood and didn’t even try it once. What the above code does is, it tells Netlify to redirect all 404 errors (that is, non existing pages) that match the from string to the to string.

Based on the docs it seems like that code will match the rules and then reply with 404 status on the matching pages. I need a 301 response.

So, unless you’re sure about the URLs that are not going to exist, you can’t do that without 404 at least as of now. You can’t use /* wildcard entry because it will match all URLs on the domain including the root of the domain.

According to docs if I use force=false it will correctly serve existing files and apply the rule to everything else. So it should do what I want. BUT:

  1. It doesnt
  2. Responses are completely random some correctly, some wrong. 0 consistency

So, according to what I read here: How to Create Better Redirect Rules for SPAs with Netlify, the redirects you’re talking about would work only when the path exists but there’s no index.html for that path. Instead, if that path has an index.html it’ll show up.

Quoted from that page:

  from = "/docs/routing/redirections"
  to = "/docs/routing/redirects"
  status = 301

If Netlify finds an index.html page under the path /docs/redirections it will serve that file up in place of handling the redirect. This feature is known as file shadowing. Broadly speaking, this behavior tends to be preferred when setting up redirect rules and routing in SPAs.

1 Like

Seems like support doesn’t care and nothing seems to help. I reverted everything and had to use a different method to achieve my goals.

I assure you that we care, @ack22. Despite that, not every question has an answer, and we hadn’t gotten to yours yet since @hrishikesh seemed to be helping you out.

Looking back over the thread, I think you have diverted from your original goal:

  • Serve existing static pages normally.

We do that automatically, so no redirect should be needed. (you can already load appfleet edge hosting pricing with NO other configuration, if you have deploy

This redirect does that:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 301
  force = false

I can’t easily tell which deploy you were working with 8 days ago when you wrote in, so it is hard to see into the past to understand your failure modes. But, looking at your current deploy, you have no more redirect in place like that - it’s all for specific paths.

Perhaps you could link me to a deploy where the redirect was in place, so I can see the misbehavior more directly than some out of date curl outputs you’ve posted? You can link to the deploy’s logs page in our UI to show me a specific older deploy, which I can connect to directly and examine in our database to understand what redirect got deployed and how it is working.

Thanks in advance for your help in troubleshooting!