Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Static Mode With Catch-all Capability #94

Open
Janaka-Steph opened this issue Apr 20, 2020 · 3 comments
Open

[Feature Request] Static Mode With Catch-all Capability #94

Janaka-Steph opened this issue Apr 20, 2020 · 3 comments

Comments

@Janaka-Steph
Copy link

This issue is a feature request asking to add a catch-all capability to the static mode.
The static server should redirect every possible url pointed to the function to the root path.
Example: http:127.0.0.1:8080/function/hello/subpath -> http:127.0.0.1:8080/function/hello

In Nginx, this is accomplished with the try_files directive.
https://docs.nginx.com/nginx/admin-guide/web-server/serving-static-content/#trying-several-options

Current Behaviour

Currently, requesting any function subpath, i.e http:127.0.0.1:8080/function/hello/subpath, will return a 404 error.

Context

This capability is mandatory in the context of Single Page Applications, like React.js apps.
Using Hash History adding # in the URL brings other issues and is not a valid solution for professional modern web applications.
A Single Page Application technically only have a single index.html, and a server should redirect every possible url pointed to the domain at this index.html located at the root.

In Nginx, we implement a catch-all rule for SPA like so:

location / {
    try_files  $uri  $uri/  index.html;
}

Link to your project or a code example to reproduce issue

Minimal React.js Single Page Application packaged for OpenFaaS with the dockerfile template and the watchdog in static mode: https://github.com/Janaka-Steph/react-spa-openfaas

@alexellis
Copy link
Member

Hi @Janaka-Steph thanks for your interest in the project and for writing up an example.

Using Hash History adding # in the URL brings other issues and is not a valid solution for professional modern web applications.

Can you substantiate that claim?

If you redirect every URI to index.html, how do you expect to serve your CSS and JS bundles? I don't quite follow that part.

Alex

@Janaka-Steph
Copy link
Author

Janaka-Steph commented Apr 20, 2020

If you redirect every URI to index.html, how do you expect to serve your CSS and JS bundles?

Yes, we should not redirect every possible url, only the ones that fails. In Nginx, the try_files directive will try the request, and fallback otherwise. In Express.js, we apply the static middleware before any others.

Why not Hash History?

The first issue is subjective, I think that a # in the url is ugly.
The second issue is that Hash History is not SEO friendly.

Feel free to close this issue if you think that adding this feature is out of the scope of the static mode.

@matart15
Copy link

matart15 commented Nov 6, 2020

I want this to be implemented as well.

Now I am using an unnecessary express server to serve my react app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants