-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Open
Labels
good first issueIssue that doesn't require previous experience with GatsbyIssue that doesn't require previous experience with Gatsbystatus: confirmedIssue with steps to reproduce the bug that’s been verified by at least one reviewer.Issue with steps to reproduce the bug that’s been verified by at least one reviewer.topic: frontendRelates to frontend issues (e.g. reach/router, gatsby-link, page-loading, asset-loading, navigation)Relates to frontend issues (e.g. reach/router, gatsby-link, page-loading, asset-loading, navigation)type: bugAn issue or pull request relating to a bug in GatsbyAn issue or pull request relating to a bug in Gatsby
Description
Description
This resumes #31504.
When a pathPrefix is used and the hosting is configured to redirect from the root domain to the pathPrefix (perfectly reasonable behaviour I think), triyng to load a non-existing page breaks React .
Steps to reproduce
Reproduction was provided in said issue and in related discussion #31531.
Expected result
The 404 page should be visible and interactive.
Actual result
The 404 page is loaded but React breaks with "Error: page resources for /xxx not found. Not rendering React.", and the page is not interactive (js is broken).
Investigation
I've debugged the issue carefully, and I've traced down the root cause:
this line:
gatsby/packages/gatsby/cache-dir/loader.js
Line 526 in 2eb57c7
return doFetch(rawPath, `HEAD`).then(req => { |
tries to check a resource existence (comment says "check if html file exist using HEAD request: if it does we should navigate to it instead of showing 404").
The error is that the rawPath it's using, is stripped from the pathPrefix. As I can see, this is used because the internal db of fetched resources is normalized, and anywhere else this function is used:
const createPageDataUrl = path => { |
But there the check is done without the pathPrefix, so it calls the incorrect url. This is not usually a problem because it would normally catch another non-existing url, so the result is the same, but with the described hosting behaviour, anything called on the root is redirected on the pathPrefix (with a 302), so this check fails, incorrectly triggering an error.
Metadata
Metadata
Assignees
Labels
good first issueIssue that doesn't require previous experience with GatsbyIssue that doesn't require previous experience with Gatsbystatus: confirmedIssue with steps to reproduce the bug that’s been verified by at least one reviewer.Issue with steps to reproduce the bug that’s been verified by at least one reviewer.topic: frontendRelates to frontend issues (e.g. reach/router, gatsby-link, page-loading, asset-loading, navigation)Relates to frontend issues (e.g. reach/router, gatsby-link, page-loading, asset-loading, navigation)type: bugAn issue or pull request relating to a bug in GatsbyAn issue or pull request relating to a bug in Gatsby