Gatsby: Prefetch header with request /page-data//page-data.json giving 404

Created on 17 Dec 2019  路  19Comments  路  Source: gatsbyjs/gatsby

Description

I'm getting 404 for prefetch request /page-data//page-data.json . This is server side generated prefetch header. Not sure where is this double slash coming from, possibly something is missing between these 2 slashes..

I've index.js inside src/pages/ folder.

These are the headers... see the prefetch header in second last line below..

gatsby-bug

<link as="script" rel="preload" href="/commons-2c9fa17bbfe249a3b2aa.js">
<link as="script" rel="preload" href="/app-ba96dfa6db2f113437ba.js">
<link as="script" rel="preload" href="/webpack-runtime-fe18612f865ab4668483.js">
<link as="fetch" rel="preload" href="/page-data/index/page-data.json" crossorigin="anonymous">
<link rel="prefetch" href="/page-data//page-data.json" crossorigin="anonymous" as="fetch">
<script charset="utf-8" src="/component---src-pages-404-js-618c1a666ce570d61585.js">

Environment

System:
OS: Windows 10
CPU: (4) x64 Intel(R) Core(TM) i5-2400S CPU @ 2.50GHz
Binaries:
Yarn: 1.16.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
npm: 6.7.0 - E:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 44.18362.329.0
npmPackages:
gatsby: ^2.18.11 => 2.18.11
gatsby-plugin-manifest: ^2.2.26 => 2.2.30
gatsby-plugin-react-helmet: ^3.1.18 => 3.1.18
gatsby-plugin-remove-generator: ^1.0.4 => 1.0.4
gatsby-plugin-robots-txt: ^1.5.0 => 1.5.0
gatsby-plugin-sass: ^2.1.20 => 2.1.24
gatsby-plugin-sitemap: ^2.2.24 => 2.2.24
gatsby-source-graphql: ^2.1.25 => 2.1.25

help wanted awaiting author response

Most helpful comment

I am experiencing the same issue and looking for a solution that works

All 19 comments

Hi @jitendra-koodo

This looks weird indeed! To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

Thanks for using Gatsby! 馃挏

I think it happens if I use canonical url as "/" for home page ... Investigating further...

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 馃挭馃挏

I am experiencing the same issue and looking for a solution that works

@MauriceOppenberger are you able to share a reproduction for one us to investigate? That would be super helpful :)

I also get this error on console. I think its related.

Error loading a result for the page query in "". Query was not run and no cached result was found.

@jitendra-koodo I tried out a couple of different things and here is what caused my issue:
In my WordPress backend, I used a custom menu item to create a dropdown. The custom link (eg. #, /), however, caused the error. When I removed the custom link and replaced it with a valid slug (eg. /home) the error disappeared. It's a silly error but try checking all your links and slugs and make sure all of them pointing to a valid path. Hope that helps

@MauriceOppenberger Thanks. I also suspected this. As I had posted earlier, I thought canonical url as "/" for home page was the culprit. Unfortunately I can not remove that canonical. I'll try few things and post my updates.

Same issue after applying custom slug for my Markdown page

Same issue with me also. Anybody found any solutions for this?

Sorry to hear you're running into an issue. To help us best begin debugging the underlying cause, it is incredibly helpful if you're able to create a minimal reproduction. This is a simplified example of the issue that makes it clear and obvious what the issue is and how we can begin to debug it.

If you're up for it, we'd very much appreciate if you could provide a minimal reproduction and we'll be able to take another look.

Thanks for using Gatsby! 馃挏

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 馃挭馃挏

Same issue for me here

Im happy to share my repo with someone to look at if they can get in touch?

I think i have you on slack @TylerBarnes

Hiya!

This issue has gone quiet. Spooky quiet. 馃懟

We get a lot of issues, so we currently close issues after 30 days of inactivity. It鈥檚 been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 馃挭馃挏

@joebentaylor1995 my email is [email protected]

This problem may be due to incorrect usage of Gatsby's <Link> component: to use this component to in-route navigation.

If you use this component for external link, similar issue will occurs.

Use a tag for in-route navigation or external link.

For more information, check the Gatsby Link API documentation.

As @ygkn mentioned, the culprit in my case a wrong href in my Gatsby component:

If you use slugs in your gatsby-node.js they are generated as: /slug-path/

So if you build your href like

// route = "https://domain.xyz/blog/"
// slug = "/path-to-slug/"
const to = route + slug;

you get a faulty https://domain.xyz/blog//path-to-slug/ which shows up in your prefetch href.

Correct the href like this:

// route = "https://domain.xyz/blog/"
// slug = "/path-to-slug/"
const correctedSlug = slug.indexOf('/') === 0 ? slug.substring(1) : slug;
const to = route + correctedSlug;

Thank you for opening this!

As no reproduction was provided yet and people say that their issue was solved by correctly using gatsby-link I'll close this issue for now.

We're marking this issue as answered and closing it for now but please feel free to comment here if you would like to continue this discussion. We also recommend heading over to our communities if you have questions that are not bug reports or feature requests. We hope we managed to help and thank you for using Gatsby!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

timbrandin picture timbrandin  路  3Comments

jimfilippou picture jimfilippou  路  3Comments

3CordGuy picture 3CordGuy  路  3Comments

kalinchernev picture kalinchernev  路  3Comments

ghost picture ghost  路  3Comments