An old redirect file has been cached and doesn’t seem to go away even when a new file has been updated. I have even tried clearing cache and deploying which didn’t help.
We still get 4 invalid redirect rules even when these rules don’t exist in the redirect file anymore.
Nowhere in there is any information regarding this scenario.
I’ve even created a branch deleting the redirect file to see if the ‘invalid rules’ error will go away. But the error still persisted even when there was no redirect file. So it’s very weird that an old file has been cached in netlify build’s and I even tried to download the zip files of the deploy to see which redirect file it has but it throws an “Error during download” error always. Tried it multiple times on different builds.
Hi!
I’m facing the same problem. I 100% removed language based redirects from netlify.toml (had negative perfomance effect) and cleared cache but redirects still happen.
I downloaded deploy zip-file and netlify.toml there is without these redirects. Also deploy summary says “6 redirect rules processed”, before it was 8.
Maybe some time needed to change netlify server behaviour?
Hmm, interesting! Okay, would you please be able to provide an x-nf-request-id for a request that shouldn’t be redirected, please? You can follow these steps:
Thanks so much for having a look. After a little over an hour, it’s cleared now.
I saved the CURL response details from when it was happening and with my x-nf-request-id you guys should be able to debug this as I believe there’s a bug now that I saw many people reporting the same.
Basically, the cache was not invalidated on deployment and it took over an hour.
» curl -v https://www.duoflag.com/login/ 20:56:13
* Trying 54.206.19.82...
* TCP_NODELAY set
* Connected to www.duoflag.com (54.206.19.82) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.duoflag.com
* start date: Aug 16 07:26:22 2020 GMT
* expire date: Nov 14 07:26:22 2020 GMT
* subjectAltName: host "www.duoflag.com" matched cert's "*.duoflag.com"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fafcc00c400)
> GET /login/ HTTP/2
> Host: www.duoflag.com
> User-Agent: curl/7.64.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 150)!
< HTTP/2 301
< content-type: text/plain
< location: /
< date: Mon, 12 Oct 2020 10:28:09 GMT
< content-length: 17
< age: 1762
< server: Netlify
< x-nf-request-id: 90d2f7e0-754c-437a-857b-4b1f3fd11c56-956895
<
Redirecting to /
* Connection #0 to host www.duoflag.com left intact
* Closing connection 0
Hey! The x-nf-request-id was a request at 10:56am UTC, the second at 09:28am UTC. They’re both CURL requests which don’t relay a deploy ID. Do you have any x-nf-request-ids from organic traffic at this time which we can assess?
I did also purge the CDN cache for this site just now as a precaution, just in case something is trying to rear its ugly head!
