You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Github Pages: Configuration to avoid initial 404 Network Response #178
Apologies if this has been asked before - I am having trouble finding similar issues to this.
Is there a way to configure the deployment so the initial Network Response when navigating to different routes of the application is not 404?
I have deployed my Angular app using angular-cli-ghpages, and it works fine, except when using the Brave browser, a message pops up when navigating to different routes, saying "Sorry, that page is missing". I noticed that this happens possibly because I get a 404 Network Response to my GET Request for the page/route, but the page loads fine. Also, when serving my application locally I don't get 404 Responses when navigating to different routes.
Unfortunately, there is no way to configure GitHub Pages to avoid this.
It might be possible to achieve something like this with a custom Jekyll deployment through GitHub Actions and the Jekyll Builder, but I'm not fully aware of Jekyll's capabilities here.
The 404.html is indeed a workaround but it's not possible to change this in GitHub Pages.
No, the 404.html is the one magic trick that is the foundation for everything to work. If this really doesn't work any longer, then we have indeed an issue... 🫤
@JohannesHoppe It still works, but of course the server sends a 404 status with the first request (together with the 404.html). So nothing has changed here, but I also don't see a way to avoid the 404 at all.
@suuf I think the main issue is the hosting provider – Github pages. They haven't innovated for years, and now the good-old workaround with the 404.html file is no longer reliable. It breaks in Brave and a social preview (eg. on X, Discord...) won't be shown anymore, because the 404 is detected.
I see two options:
Fixing the issue on a higher layer. You could try to configure a provider like Cloudflare to suppress the 404 error. If you have figured out a great rule for this, then please tell me. We really need this option, too.
Prerender every file, if possible
Switch to Cloudflare pages. Just deploy into any github-repo and then connect Cloudflare pages with that repo. This works great and we have successfully used Cloudflare pages in newer projects. They have great features like a the _redirects file. But the best feature is the modern approach regarding single page apps. To support Cloudflare pages, i added the option --no-notfound in angular-cli-ghpages@2.0.0-beta.1 to not create a 404.html. Cloudflare pages will now serve the index.html by default and won't send a 404 status code! 🎉
If your project does not include a top-level 404.html file, Pages assumes that you are deploying a single-page application. This includes frameworks like React, Vue, and Angular. Pages’ default single-page application behavior matches all incoming paths to the root (/), allowing you to capture URLs like /about or /help and respond to them from within your SPA.
changed the title [-]Configuration to avoid initial 404 Network Response[/-][+]Github Pages: Configuration to avoid initial 404 Network Response[/+]on Jan 26, 2024
Activity
[-]Configuration to avoid 404 initial response[/-][+]Configuration to avoid 404 initial Network Response[/+][-]Configuration to avoid 404 initial Network Response[/-][+]Configuration to avoid initial 404 Network Response[/+]fmalcher commentedon Jan 21, 2024
Unfortunately, there is no way to configure GitHub Pages to avoid this.
It might be possible to achieve something like this with a custom Jekyll deployment through GitHub Actions and the Jekyll Builder, but I'm not fully aware of Jekyll's capabilities here.
The 404.html is indeed a workaround but it's not possible to change this in GitHub Pages.
@JohannesHoppe Do you have anything to add here?
JohannesHoppe commentedon Jan 21, 2024
No, the 404.html is the one magic trick that is the foundation for everything to work. If this really doesn't work any longer, then we have indeed an issue... 🫤
fmalcher commentedon Jan 22, 2024
@JohannesHoppe It still works, but of course the server sends a 404 status with the first request (together with the 404.html). So nothing has changed here, but I also don't see a way to avoid the 404 at all.
fmalcher commentedon Jan 22, 2024
Closing this for now as it's rather an issue around GitHub Pages, not with this tool.
JohannesHoppe commentedon Jan 22, 2024
But it's indeed a huge issue with Brave, see this:
JohannesHoppe commentedon Jan 26, 2024
@suuf I think the main issue is the hosting provider – Github pages. They haven't innovated for years, and now the good-old workaround with the
404.htmlfile is no longer reliable. It breaks in Brave and a social preview (eg. on X, Discord...) won't be shown anymore, because the 404 is detected.I see two options:
_redirectsfile. But the best feature is the modern approach regarding single page apps. To support Cloudflare pages, i added the option--no-notfoundinangular-cli-ghpages@2.0.0-beta.1to not create a404.html. Cloudflare pages will now serve theindex.htmlby default and won't send a 404 status code! 🎉FYI Cloudflare docs: Single-page application (SPA) rendering
If your project does not include a top-level
404.htmlfile, Pages assumes that you are deploying a single-page application. This includes frameworks like React, Vue, and Angular. Pages’ default single-page application behavior matches all incoming paths to the root (/), allowing you to capture URLs like /about or /help and respond to them from within your SPA.https://developers.cloudflare.com/pages/configuration/serving-pages/#single-page-application-spa-rendering
[-]Configuration to avoid initial 404 Network Response[/-][+]Github Pages: Configuration to avoid initial 404 Network Response[/+]fix: audit remediation - code quality and documentation improvements