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: fallback path when backend returns 404 #606

Open
manuel-guilbault opened this Issue Nov 27, 2017 · 5 comments

Comments

Projects
None yet
3 participants
@manuel-guilbault

manuel-guilbault commented Nov 27, 2017

I heavily use Azure Functions proxies to serve single page applications stored in a Blob Storage container. However, when those applications use push state-based routing, deep linking doesn't work by default because the web server is expected not to return a 404, but to fall back to index.html (or some other default document) when the requested path is not found. This way, the client app is loaded and its router can notice that the current path is the root directory and can load the property view based on its routing table.

At the moment, I end up copy & pasting the same function acting as proxy with this fallback mechanism in all of my apps. It would be pretty neat if Azure Functions proxies supported this.

@paulbatum

This comment has been minimized.

Show comment
Hide comment
@paulbatum

paulbatum Nov 27, 2017

Member

@safihamid any thoughts on this?

Member

paulbatum commented Nov 27, 2017

@safihamid any thoughts on this?

@safihamid

This comment has been minimized.

Show comment
Hide comment
@safihamid

safihamid Nov 27, 2017

@manuel-guilbault could you please provide some examples of what you do today and what you think should be supported?

safihamid commented Nov 27, 2017

@manuel-guilbault could you please provide some examples of what you do today and what you think should be supported?

@safihamid safihamid self-assigned this Nov 27, 2017

@manuel-guilbault

This comment has been minimized.

Show comment
Hide comment
@manuel-guilbault

manuel-guilbault Nov 28, 2017

@safihamid sure :)

Today my code acts just like a proxy. The only difference is that, if the backend returns a 404, my function
drops the 404 response and falls back to sending another request for index.html to the backend. Then it just pipes the response of this second request back to the client.

The new feature I'd like to see is being able to specify fallback paths per HTTP status code for a given proxy. The proxy would then follow this algorithm:

  1. Upon receiving a request, it forwards the request to the backend.
  2. Upon receiving the response from the backend, it checks if its status code matches one of the fallback paths' status code.
    a. If no matching fallback path is found, it just sends the response back to the client, just like it actually does.
    b. If a matching fallback path is found, it drops the response and sends a new request to the matching fallback path, then forwards the new response to the client.

This would allow to use proxies not only to handle deep linking for single page applications, but also to support different response overriding scenarios such as custom error pages.

manuel-guilbault commented Nov 28, 2017

@safihamid sure :)

Today my code acts just like a proxy. The only difference is that, if the backend returns a 404, my function
drops the 404 response and falls back to sending another request for index.html to the backend. Then it just pipes the response of this second request back to the client.

The new feature I'd like to see is being able to specify fallback paths per HTTP status code for a given proxy. The proxy would then follow this algorithm:

  1. Upon receiving a request, it forwards the request to the backend.
  2. Upon receiving the response from the backend, it checks if its status code matches one of the fallback paths' status code.
    a. If no matching fallback path is found, it just sends the response back to the client, just like it actually does.
    b. If a matching fallback path is found, it drops the response and sends a new request to the matching fallback path, then forwards the new response to the client.

This would allow to use proxies not only to handle deep linking for single page applications, but also to support different response overriding scenarios such as custom error pages.

@safihamid

This comment has been minimized.

Show comment
Hide comment
@safihamid

safihamid Nov 28, 2017

@manuel-guilbault thanks, we will look into it in our planning.

safihamid commented Nov 28, 2017

@manuel-guilbault thanks, we will look into it in our planning.

@manuel-guilbault

This comment has been minimized.

Show comment
Hide comment
@manuel-guilbault

manuel-guilbault commented Nov 29, 2017

@safihamid awesome thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment