Error 404 for SPA (Single Page Application)

[paulocoutinhox]

Hi,

Im making a project that is a SPA, and i want host on github instead of Netlify.

But github still not support redirect all to index.html.

How i can do it with this new deploy method?

Today im using the 404.html file, but it shows http status 404, what is bad :(

Can we have something similar to 200.html and http status 200 or something that redirect all to 404.html?

Repository:
https://github.com/sqlitedb/sqlitedb.github.io

Workflow:
https://github.com/sqlitedb/sqlitedb.github.io/blob/main/.github/workflows/pages.yml

Http Status Error:
https://sqlitedb.github.io/about

Thanks.

[yoannchaudet]

Until we support custom headers (and redirections), I think you will need to live with the 404.html trick (e.g. as mentioned here).

For now, you could mask the 404 status code by just doing an extra client side redirection from your 404.html to your index.html (router).

We don't have an ETA at the moment for when we will have proper support for custom headers and redirection. This is on our radar though.

[yoannchaudet]

Our intent is to make all Pages builds and deployments happen in Actions in the future. Given your repository is public, it has been building with Actions already since December 2021.

The main difference for you now is that you have full control over the workflow. Some future features will require Actions (e.g. being able to preview a Pages site on a PR).

When you deploy with a custom workflow, you also don't need any "magic files" anymore (CNAME or .nojekyll). You can remove that one already: https://github.com/sqlitedb/sqlitedb.github.io/blob/main/.nojekyll.

Another pros of having a custom workflow is that you have full control over the build. Instead of committing your compiled assets you could also have that happen in a build step in your workflow. With reusable workflows being a thing nowadays, you could maybe even have the build step continue to live in your other repo closer to the code.

[paulocoutinhox]

Ok, so the magic of auto page publication of files in "https://github.com/sqlitedb/sqlitedb.github.io" will die in future, correct?

But what i don't understand and still dark to me, and i don't find in docs, is how i can publish to domain "https://sqlitedb.github.io" from repository "sqlitedb" without the repository "sqlitedb.github.io".

If i can publish to pages of my app "https://sqlitedb.github.io" from repository "sqlitedb" without need repository "sqlitedb.github.io", i can delete repository "sqlitedb.github.io", correct?

I don't find this info anywhere.

[yoannchaudet]

We are not changing the semantic of having a repository named {user or org}.github.io in order to publish a site directly on that domain.

Nor are we planning on making things more difficult than they need to be. If you are happy with your current state, rest assure it is not going to break.

[harry-pham-wise]

hi @yoannchaudet is there an estimation or roadmap on when github will support custom headers. My app works with the 404 trick, but since Github is return 404, it can't be picked up by Google SEO.

[paulocoutinhox]

I need it too :(

[pjebs]

Until we support custom headers (and redirections), I think you will need to live with the 404.html trick (e.g. as mentioned here).

For now, you could mask the 404 status code by just doing an extra client side redirection from your 404.html to your index.html (router).

@yoannchaudet Why is support for custom headers (and redirections) required if a 200.html file can be used instead and operate similarly to the 404.html file?

Is it because you want to build a comprehensive solution rather than another "ad-hoc" band-aid solution?

In terms of masking the status code, google does not seem to appreciate it.

[yoannchaudet]

Correct we are trying to keep the amount of band-aids low so it does not become some impossible technical debt we need to cary forever as we make more sweeping changes.