Handling path rewrite / redirect to normalize it before accessing SPA

Question

I have to handle the path that the user is accessing my SPA app, which is being delivered through a CloudFront distribution.

The path is domain.com/client-slug/country-slug/language-slug/....

These 3 path params, client-slug, country-slug and language-slug need to be present for the SPA to work properly.

The client-slug is mandatory: without it, the user needs to be redirected to a default one, and the Location Path needs to be rewritten. This client-slug is sended through an REST API to check if it exists, is valid and is online, bringing back the country and the language available for the access being made. If a country and / or a language are informed in the user access, they are used in this request, so they can be validated too.

The country-slug is calculated using CloudFront's country header. If it's wrong, missing, or has the placeholder WorldWide ww value, the user needs to be redirected to the CF's one.

Same for the language-slug, but only if this language is available for the country previously defined.

So, for example, here we have a list of Original Location Path to Final Location Path:

domain.com => domain.com/default-slug/country/language
domain.com/events =>  domain.com/default-slug/country/language/events
domain.com/valid-client-slug =>  domain.com/valid-client-slug/country/language
domain.com/valid-client-slug/events =>  domain.com/valid-client-slug/country/language/events

Also, the application is written in AngularJS, so it needs to route the user to an entry file, index.html in this case.

• How can I handle the proper routing of the user following the behavior described using a Lambda@Edge function?
• In which trigger should I put the function?
• The process to return the entry file needs to be in the same trigger / function or it can be in another one?

Answer 1

You can accomplish this using CloudFront Functions (CF2) on viewer request trigger. It sounds like you need two things:

1. Determining the country of the viewer for each request (which in turn is used to determine the language).
2. Rewriting the request, and ensuring identically rewritten requests are cached (if you utilize caching)

For 1, you can use the CloudFront country headers as you mentioned above. In order to access these HTTP headers from a CF2 function, you'll need to include them in your origin request policy so they are available to the CF2 function. I would suggest not putting them in your cache policy because you will be rewriting the URI anyway that will be used for the cache key. And yes, although you add the headers in an origin request policy, they are normalized and available to a CF2 function that executes on a viewer request trigger.

For 2, you'll want to update the request URI sent to the origin in the function. This updated URI will be used to compute your cache key, ensuring requests are cached by CF. This is a good reference function to use as an example for implementing a URI rewrite with CF2:

https://github.com/aws-samples/amazon-cloudfront-functions/tree/main/url-rewrite-single-page-apps