github pages 404 error on static files first time

[subsid]

I am new to gatsby and facing an issue with loading static html files.

I have a component called notes.js that links to some static files like so

export default ({ data }) =>
  <div style={{ flex: "1 0 auto" }}>
    <Link to={withPrefix("/notes/note1.html")} target="_blank">some note</Link>
  </div>

The file is saved at static/notes/note1.html.
This works fine in development, http://localhost:8000/notes/note1.html opens as expected when I click on the link.
But when I deploy the same, the first time I click on the link, it goes to github's 404 page.
But works fine on subsequent clicks.

Have I misconfigured something in gatsby?
gatsby repo: https://github.com/subsid/blog-skeleton

Thanks for your great work.

[peduarte]

What error are you getting?

Is it like this?

Think I'm getting the same one.

[m-allanson]

@peduarte I think your error looks different, could you open a separate issue?

@subsid Changing your <Link> components to plain <a> tags should fix it:

<a href={withPrefix("/notes/probability.html")} target="_blank">Probability</a>

I think the <Link> component is just for navigating within routes that Gatsby has created, so it doesn't know how to find your static html files.

Note that I get slightly different results using your site - in development mode clicking a link to one of the notes gives me a 404 error:

[peduarte]

@m-allanson Hey 👋

Thanks for your suggestion, I'm going to give it a try.

I was under the impression Link should be used for linking between "Gatsby" Page Components.

In my case I am actually using NavLink (from gatsby-link) in order to apply a activeClassName prop.

Do you think this could be the issue?

[m-allanson]

Hi @peduarte 👋 that suggestion was for @subsid, I don't know if it'll help in your case. Could you create a new GitHub issue explaining the error you're seeing?

[peduarte]

@m-allanson Sure!

[m-allanson]

Thanks :)

[subsid]

@m-allanson thanks for looking into it. Changing it to an a tag doesn't seem to help.

The error seems like, my gatsby-config is not respecting the link to be a client only route. Actually the page opens, and then github's 404 shows up. (If you hit back on the 404 page, it goes to the notes file). Also, if I open the link manually in a new tab, it works fine. https://subsid.github.io/notes/probability.html Its only clicking on the link that causes the issue.

Regarding your local setup, hmm, not sure why that would happen. The file is present in static/notes/. Let me try to clone the repository again and see if I can reproduce it.
PS: The issue shows up only on github pages, not locally.

[subsid]

@m-allanson I was able to recreate the issue you had locally. The first time I cloned the repo, started server and clicked the link, I got the gatsby-404 page. But on subsequent clicks, it works fine.

But if I delete /public and start the server, it again goes to gatsby-404 the first time. Something to do with the file being cached? It's the same behavior on github pages as well. I suspect my gatsby-config more now. Should I handle static pages differently?

[m-allanson]

Huh... ok! I'm not sure exactly what's happening under the hood, but I managed to work around this with these steps:

• rename your /static/notes/ directory to something else - I chose /static/static-notes
• update the links with the above new path
• disable gatsby-plugin-offline

Does that fix it on your side? If you're able to do some more digging into the source of the problem that'd be very useful!

[subsid]

Yup, that solves the issue. Disabling gatsby-plugin-offline seems to cause someother error to do with sw.js when deployed. (might be cause of my chrome extensions as well) It worked fine on firefox though.
Anyways, I'll dig into this a little more and see if I can get more info. Thanks!

[m-allanson]

I'm glad you got it working! sw.js is likely the service worker installed by gatsby-plugin-offline to handle the offline side of things.

[wawoon]

I faced the almost same problem, and I fixed it by editing navigateFallbackWhitelist options of gatsby-plugin-offline.
In my case, service worker makes cache of the client-side only page.

It was very helpful for me to read docs of sw-precache because gatsby-plugin-offline uses sw-precache internally.

[pedrouid]

I'm also facing the same issue, my question is how do you handle the already existing service worker to fix this issue or force refresh to update the changes.

@ykosaka-welyco when you updated navigateFallbackWhitelist did you manage to test on a different browser where the service worker hadn't been updated yet?

[imarem]

@pedrouid I'm facing the same issue. Have you been able to find a solution?

[pedrouid]

I have removed the service-worker completely and unregistered the existing ones

[SleeplessByte]

FWIW: not using gatsby-plugin-offline or any service worker and still having this issue.

It seems to occur because link clicks are hijacked by the router (which is fine) and subsequently var page = findPage(path) yields nothing. This is to be expected, because it's not a gatsby page but a static asset. This fails and now shows the 404 page.

When going there directly, there is no link click to be hijacked, and the gatsby router resolves correctly.

[gatsbot]

Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open!

[SleeplessByte]

not stale

…

On Sat, 19 Jan 2019, 18:16 gatsbot[bot], ***@***.***> wrote: Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4115 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB35WJepN3LdQ5tlc6H4NRcSj-LS6g4gks5vE1MLgaJpZM4SJiys> .

[gatsbot]

This issue is being closed due to inactivity. Is this a mistake? Please re-open this issue or create a new issue.

[SleeplessByte]

This is a mistake..

[wzard]

@SleeplessByte Did you figured out how to solve this issue? I am facing the same problem on production.

[SleeplessByte]

@subsid can you re-open this?
@wzard nope, we simply just leave it be.

[subsid]

@SleeplessByte I can't. I don't see the button reopen privileges

[wzard]

@SleeplessByte I added target="_blank" and href to http instead of https. It used to give 404 on primerlabs.io, but worked well on www.primerlabs.io. Now, it's working fine for both.