angular-cli-ghpages icon indicating copy to clipboard operation
angular-cli-ghpages copied to clipboard

Github Pages: Configuration to avoid initial 404 Network Response

Open suuf opened this issue 1 year ago • 6 comments

Hello!

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.

suuf avatar Jan 21 '24 14:01 suuf

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?

fmalcher avatar Jan 21 '24 19:01 fmalcher

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 avatar Jan 21 '24 21:01 JohannesHoppe

@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 avatar Jan 22 '24 17:01 fmalcher

Closing this for now as it's rather an issue around GitHub Pages, not with this tool.

fmalcher avatar Jan 22 '24 18:01 fmalcher

But it's indeed a huge issue with Brave, see this:

Screenshot 2024-01-22 at 19 34 29

JohannesHoppe avatar Jan 22 '24 18:01 JohannesHoppe

@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:

  1. 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 not this option, too.
  2. Prerender every file, if possible
  3. 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 [email protected] to not create a 404.html. Cloudflare pages will now serve the index.html by 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.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.

https://developers.cloudflare.com/pages/configuration/serving-pages/#single-page-application-spa-rendering

JohannesHoppe avatar Jan 26 '24 15:01 JohannesHoppe