I'm using Gatsby V2. I have a strange problem with 404 error because it redirects automatically to ?no-cache=1
My URL is: https://aikode-pwa-sistema.firebaseapp.com/
I executed:
show URL without "?no-cache=1"
https://aikode-pwa-sistema.firebaseapp.com/page-test-404
show URL with "?no-cache=1"
https://aikode-pwa-sistema.firebaseapp.com/page-test-404?no-cache=1
System:
OS: Windows 10
CPU: x64 Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
Binaries:
Yarn: 1.7.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 5.6.0 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 42.17134.1.0
npmPackages:
gatsby: ^2.0.0 => 2.0.1
gatsby-plugin-manifest: ^2.0.2 => 2.0.2
gatsby-plugin-nprogress: ^2.0.5 => 2.0.5
gatsby-plugin-offline: ^2.0.5 => 2.0.5
gatsby-plugin-react-helmet: ^3.0.0 => 3.0.0
gatsby-plugin-remove-trailing-slashes: ^2.0.0 => 2.0.0
Hello, that problem seems more like firebase than gatsby.
If you try to upload your application to netlify?
@devrchancay but also happens with gatsby serve (http://localhost:9000)
@davidbailey00 can't we avoid showing ?no-cache=1 if there is a 404.js component?
It's super weird, I have a project with version 2 with similar dependencies to yours and that does not happen to me, I just verified it, will not you have something like that in your 404 component?
@devrchancay this will only happen if you have added gatsby-plugin-offline in your application.
@robertoaikode This is intentional behaviour in order to prevent incorrectly displaying a 404 page - I'll have a look next week to see if I can improve how it works.
@kakadiadarpan I am using the offline plugin, as I read is a normal behavior but it does not happen for sure I have to update something.

I'm getting this same thing in production. Only plugins I have. Everything up to date
plugins: [
'gatsby-plugin-react-helmet',
{
resolve: 'gatsby-plugin-sass',
options: {
precision: 8,
},
},
],
@drewhamlett Actually this will occur without using the offline plugin too - I'll try to make some changes next week which improve the behaviour.
can't we avoid showing ?no-cache=1 if there is a 404.js component?
@KyleAMathews yep that sounds good! Worth noting that it'll still be necessary in some circumstances e.g. Netlify CMS + offline plugin (otherwise the offline shell would try handling the request).
@davidbailey00 thanks 馃槃
happening on our website as well:
https://www.kaizen.co.uk/adsdafa redirects to https://www.kaizen.co.uk/adsdafa?no-cache=1 which actually causes the page transition (using react-transition-group) to fail. Also here's the log from inspector:
A page wasn't found for "/adsdafa"
load-directly-or-404.js:18 Found no-cache=1 while attempting to load a page directly; this is likely due to a bug in Gatsby, or a misconfiguration in your project.
@b0gd4n Interesting, that error message actually indicates that there's something wrong with the 404 page itself, and Gatsby prevented an infinite loop. I'll definitely investigate this on Monday
Also I just noticed this is happening on Gatsby's own website; it looks like a recent change broke something. Sorry about all the problems :(

I'm getting a refresh loop that keeps appending that query string on our homepage that does exist. The page is not 404 and is trying to load on each refresh with another no-cache query string appended.
@abstracthat I'm seeing the same thing, Googlebot and Page Speed are complaining the homepage is a redirect loop as you described, but it doesn't happen in Chrome/Firefox for me.
Struggling to reproduce it on Netlify, will keep trying
@dbrookes I fixed it. I was using an undeclared variable but the error was swallowed in dev. I suspect this is the actual issue. The page JS couldn't load correctly so it thought it was not found but the router says load this file, so it got stuck in a loop. In the same deploy I also updated to the latest Gatsby plugins (minor point versions), so it's also possible that was the fix, but I suspect the latter.
@abstracthat With the latest changes, the infinite loops have been fixed so now you'll see a console log saying "Found ?no-cache=1 when trying to directly load page. This is probably a misconfiguration with your app, or a bug with Gatsby" in places where an infinite loop would happen.
Is this fixed? I get this issue as well.
@dumblole The changes were only just published a few hours ago, so if you run yarn upgrade now it should be fixed. Let us know if you're still having any issues :)
Can confirm upgrading to gatsby 2.0.10 fixed this for me
Thanks! Works like a charm. 馃憣
gatsby v2.4.1 still produces this error. Can you please look into this?
Hey @DavidTheSimon, please can you open a new issue describing the problem? I'll be happy to have a look at this, but I need a demonstration repository so I can see the cases when it's happening.
N.b. in certain cases, ?no-cache=1 is still required in order to display the correct page so it will still occasionally be displayed in the address bar - if you can open an issue with better proposed behaviour I'd be happy to look into this.
I had this issue with production builds only when serving the site from S3/Cloudfront
I had forgotten to tell S3 where the 404 page is, and it returned the no-cache thing.
Setting the error document fixed it

I had this issue on a production build when serving from an Azure Web App. It seems obvious now but you need to have a Web.Config file which will redirect 404 errors to the /404/index.html page. I created my web.config and put it in the static folder so is inserted in the public folder on build.
The part of my web.config which needed to be added:
<httpErrors errorMode="Custom" defaultResponseMode="ExecuteURL">
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" path="/404/index.html" responseMode="ExecuteURL" /
</httpErrors>
Thanks @mikbeach, that sounds promising. Never thought of that. I'll definitely give it a go next week and get back here with my results on Nginx server.
Running into the same issue. gatsby 2.0
@rotexhawk The ?no-cache parameter has been removed from recent versions of Gatsby, please update your plugins and try again :)
Most helpful comment
@drewhamlett Actually this will occur without using the offline plugin too - I'll try to make some changes next week which improve the behaviour.