'How does modifying request.uri affect CloudFront's cache behaviour?
When you configure a behaviour in a CloudFront distribution, you specify a few values including:
- A path pattern, e.g.
images/* - The origin to select
- A cache policy
When a request arrives, CloudFront compares the request's path to the path pattern and uses it to select the origin and the cache policy.
It's possible to modify the request path in a Lambda@Edge viewer request function, by setting a new request.uri.
But what happens if the modified request.uri now matches a different path pattern to the original request? How does modifying request.uri affect the origin selection and cache policy selection?
The Lambda@Edge docs explain that the viewer request function runs before the cache lookup, but it's not clear how Lambda@Edge affects the cache policy.
We've tried this out in CloudFront, because we have to handle some complex path-based origin selection rules. We found that requests are routed to the origin that we expect (based on the request.uri set in the Lambda@Edge function, and the path rules) but the cache hits and misses seem to be following the default cache policy rather than the one configured for that origin.
So it looks to us like:
- Origin selection uses the modified
request.uri - Cache policy selection uses the original URL
Is that the expected behaviour? I can't find a definitive answer in the docs, and we were surprised that the behaviour is inconsistent.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|
