4 ms·

CloudFront Distributions cannot pass the request to CloudFront Functions before sending to the origin. In other words, they cannot be used to modify origin requ

CloudFront Distributions cannot pass the request to CloudFront Functions before sending to the origin. In other words, they cannot be used to modify origin request/responses. They can only modify the viewer request/responses. [0] Only Lambda@Edge can help the scenario which I provided, which is also AWS's recommended solution. [1] [0] https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [1] https://aws.amazon.com/blogs/architecture/serving-content-using-fully-managed-reverse-proxy-architecture/ https://aws.amazon.com/blogs/architecture/serving-content-us...

ep103 5y ago
Personally, I did it with templates in api gateway, as at least then I'm not paying for the cpu time to do these sorts of manipulation. But yes, stuff like this made me really shake my head at 'the cloud'
forty 5y ago
From your link [0] "URL redirects or rewrites" is a supported use case. For stripping /api/ from the path, I don't know what would be the benefit of doing it at the origin request, rather than at the viewer request? Cloudfront functions are pretty new, so some older docs might still reference lamdba@edge only.
- herpderperator 5y ago
  The origin request is your backend. The viewer request is the one you're requesting from the client. You want the viewer to have /api. You want the origin to not have /api. Therefore stripping must be performed on the origin request, which is not supported by CloudFront Functions.
  - forty 5y ago
    Both the viewer request and origin request hook both happen early enough that you can update the path See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... I have used lamdba@edge and our primary use case was to rewrite url (to add languages information for example) so I'm sure it works in viewer request events.
    - herpderperator 5y ago
      No. Please see the many other responses I gave to other comments. It does not work because the viewer request is the request the viewer views. If you change the URL of the viewer request, CloudFront sends a 301 accordingly. In other words, changing /api/blah to /blah in the "Viewer Request" part results in CloudFront injecting a `301 location: /blah` and the client doesn't hit your backend because they got redirected. The client instead hits your frontend as a result of your URL rewrite. There is a very clear difference between viewer and origin. If you could rewrite origin requests at the viewer level there would not be any difference between the two. This is the difference. Viewer is what the client sees. Origin is what the backend sees.
      - forty 5y ago
        My understanding is that you would need to rewrite the url and update the origin. I could be wrong as I did this lambda@edge a while ago, but the main difference between the two request event is that viewer request is done in all cases, while origin request is done only in case of cache miss. [EDIT] you are right, updating the origin is indeed something that cannot be done on the viewer side. My bad, I should have checked earlier.

ep103 5y ago

Personally, I did it with templates in api gateway, as at least then I'm not paying for the cpu time to do these sorts of manipulation. But yes, stuff like this made me really shake my head at 'the cloud'

forty 5y ago

From your link [0] "URL redirects or rewrites" is a supported use case. For stripping /api/ from the path, I don't know what would be the benefit of doing it at the origin request, rather than at the viewer request? Cloudfront functions are pretty new, so some older docs might still reference lamdba@edge only.

herpderperator 5y ago
The origin request is your backend. The viewer request is the one you're requesting from the client. You want the viewer to have /api. You want the origin to not have /api. Therefore stripping must be performed on the origin request, which is not supported by CloudFront Functions.
- forty 5y ago
  Both the viewer request and origin request hook both happen early enough that you can update the path See https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/images/cloudfront-events-that-trigger-lambda-functions.png https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... I have used lamdba@edge and our primary use case was to rewrite url (to add languages information for example) so I'm sure it works in viewer request events.
  - herpderperator 5y ago
    No. Please see the many other responses I gave to other comments. It does not work because the viewer request is the request the viewer views. If you change the URL of the viewer request, CloudFront sends a 301 accordingly. In other words, changing /api/blah to /blah in the "Viewer Request" part results in CloudFront injecting a `301 location: /blah` and the client doesn't hit your backend because they got redirected. The client instead hits your frontend as a result of your URL rewrite. There is a very clear difference between viewer and origin. If you could rewrite origin requests at the viewer level there would not be any difference between the two. This is the difference. Viewer is what the client sees. Origin is what the backend sees.
    - forty 5y ago
      My understanding is that you would need to rewrite the url and update the origin. I could be wrong as I did this lambda@edge a while ago, but the main difference between the two request event is that viewer request is done in all cases, while origin request is done only in case of cache miss. [EDIT] you are right, updating the origin is indeed something that cannot be done on the viewer side. My bad, I should have checked earlier.