The version of the URL with .html works fine, but without the .html it is redirecting even though we have removed the relevant rules from the _redirects file.
Is there some sort of caching of 301 redirects, and if so, can we invalidate that cache?
On our branch deploys the same url works fine, (for example x-nf-request-id: 0f82060a-04c9-4b72-b761-7cac1f72f4c1-25462232)
which is why we think it might be some sort of caching issue.
As discussed in the mistargeted Helpdesk ticket, we’ll need you to reconsider using Cloudflare in front of Netlify because this is a known anti-pattern with our atomic deploys and caching configuration.
We weren’t using cloudflare at the time. I put cloudflare in after the fact to workaround the issue, so that we could redirect the non html url to the html url and bypass the errant 301 netlify was serving.
Appreciate that. However, we’ll not be able to debug with it in place. Proxying to us and having an active split test (as examples) are two of the ‘these can’t be in place’ things before our wider team will investigate a cache inconsistency.
That said, I tried purging your site’s cache earlier but this is ineffective when it’s cached elsewhere. Additionally, requests which we serve are all from the same deploy, 5f95a919f3e8830007fc868e.
Unfortunately debugging things is going to be a bit awkward to test because the site in question is for a board game where you get a “secret” URL at a certain point when you win the game, so
we don’t want the URL showing up in google results, so I’m hesitant to put in the actual URL in this conversation.
The URL is printed on a physical card in the board game and we were getting dozens of users complaining about the redirect so we had to put in a hacky workaround with cloudflare even though, as you said, cloudflare ideally shouldn’t be used with netlify.
My hands are kind of tied because our workaround is working now and we can’t afford any downtime lest our customer support folks get hammered with angry users.
The problem persists though: without cloudflare redirecting to the url with ‘.html’ at the end, netlify is serving an incorrect 301 redirect to https://boxonegame.com which shouldn’t be there. Neither the netlify.toml nor the _redirects file have such a redirect defined. They used to have such a redirect but it was removed on Saturday.
Something on netlify’s end has cached that 301 redirect which shouldn’t be there.
Doesn’t look like we’re able to ascertain the deploy ID from at request as it was non-organic (i.e. cURL UA, rather than a legitimate traffic source). We’d need a request-id from an organic browse to the site.
Therefore, I can’t check what rules are being applied
I don’t want to leave you stuck in the mud… so, as a bit of a workaround/frig, have you considered a new redirect rule that’ll force the page to not redirect, with a rule like:
I have a similar issue. I deployed a redirect during temporary maintenance. The redirect was only up for a few hours but continues to be active.
I tried the redirect rule as suggested, but I get a Netlify 404 page.
[[redirects]]
from = “/the-url”
to = “https://www.thedomain.com/the-url”
status = 200!
Here are some of the request ids for what I need cleared:
x-nf-request-id: cb52f33d-0f9e-4bb0-8db1-b4a649cf6fcd-1228529
x-nf-request-id: 8cf0e1c0-9c57-4997-b46e-d08101664c82-355205
x-nf-request-id: f9522112-19af-4fc5-bdc6-2b8b5f0dea7e-1325633
Ideally, we would like to be able to clear these out ourselves or dump any ‘cache’ or clear such items out ourselves.
Interesting. There’s nothing astray and our CDN is serving the same deploy across all PoPs (both example routes above are 200-ing and all to the same, current deploy ID ending ddca).
Unfortunately, because of the proxy, I’m not able to grab the deploy IDs used back when this was occurring. But, for your last x-nf-request-id, f9522112-19af-4fc5-bdc6-2b8b5f0dea7e-1325633, this in fact was 200ing.