CloudFront provides two mechanisms associated with a URL.
One of these is the cache pattern of the path pattern , which determines which paths are routed to which origin.
The path template /foo/* will send all requests matching /foo/* to the specified beginning using the path in the original request, so GET /foo/bar will be sent as it is, GET /foo/bar to the outgoing request to the beginning
... if ... the path is changed using the origin path , which adds a prefix to the beginning of each outgoing request at the origin.
If the beginning indicated above has the origin path /baz , then the outgoing request to the origin will be GET /baz/foo/bar .
Then there is no mechanism for removing path components — only for adding them.
Configuration parameters cannot remove path components until the request is redirected to the beginning. If GET /foo/bar should be sent to the origin as GET /bar ... CloudFront does not currently have this capability.
CloudFront alone is not able to delete or otherwise rewrite the path that will be sent to the beginning, but Lambda @Edge does. Lambda @Edge is a CloudFront feature that allows you to configure triggers that fire at 4 different points during request processing, and change parts of the request (including path and headers) or response (headers) using code written in Node.js.
CloudFront creates a data structure representing the attributes of the request and calls the Lambda function, passing the structure as an argument to event . The response from the Lambda function changes the behavior of CloudFront accordingly.
There are 4 trigger points. You can use any combination of them for each cache behavior.
- View request triggers fire after the initial match to the cache path pattern matches, but before the cache is checked. Here you can check the incoming request from the browser, change the path and headers, and even - depending on the contents of the request - generate a simple response directly from the Lambda function, which returns to the browser without further processing from CloudFront. Changing the path here will change the path that CloudFront uses to find the cache, but does not cause CloudFront to choose a different cache behavior. After checking the cache, the response may be returned to the observer in the event of a cache hit, or processing may continue inside CloudFront.
- The source request fires when CloudFront does not have a cached copy of the object before the request is sent to the beginning. The path and headers can be changed here, and simple responses are generated directly without sending a request to the source if necessary. This trigger will not change the choice of cache behavior, even if you rewrite the path. When you need to rewrite a path, this is usually the most economical trigger to use, since it only fires when the object is not already in the cache. (In contrast, a view request trigger is fired for each request.)
- Origin Response fires when a response is returned from the source, before the object is cached and returned to the observer. You can check the original request here, but it's too late to modify it. You can change the response headers. This is especially useful for sources that do not set the
Cache-Control headers you want. Setting the Cache-Control headers here affects the behavior of the CloudFront browser and the browser. This trigger does not work on errors, only the initial responses with HTTP status codes <400. - The viewer’s actions fire before CloudFront returns the object to the viewer, regardless of whether it was downloaded from the source or sent from the cache. Response headers are subject to change.
For the solution application discussed here, the Lambda @Edge Origin Request trigger is required to remove a known prefix from the request path after checking the cache, but before sending the request to the source server.