3 ms·

Not sure why you cannot strip in your backend, and it's a huge deal. Code needs to be run somewhere though. While Lambda@Edge sucks, Cloudfront runs functions n

by CSDude 5y ago

Not sure why you cannot strip in your backend, and it's a huge deal. Code needs to be run somewhere though. While Lambda@Edge sucks, Cloudfront runs functions now which is not Lambda@Edge, and faster because it executes on the PoP location. https://aws.amazon.com/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale/ https://aws.amazon.com/blogs/aws/introducing-cloudfront-func...

herpderperator 5y ago
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...
- CSDude 5y ago
  I've just tried it. The following function works exactly as-is when the function is configured as Viewer request. I changed it to append some text to URL. See: https://github.com/aws-samples/amazon-cloudfront-functions/blob/main/url-rewrite-single-page-apps/index.js https://github.com/aws-samples/amazon-cloudfront-functions/b...
  - herpderperator 5y ago
    That MODIFIES a viewer request, resulting in a viewer redirect. We want to keep the viewer request the same, i.e. with /api, and strip it only from the backend origin request. The viewer request is the one you make from the client, with /api. The origin request is the one CloudFront sends to your backend, which, without using Lambda@Edge via the origin request, will get sent as-is with the /api prefix. You have to strip it from the origin request. If you strip /api from the viewer request, your `domain.com/api/users` request becomes a redirect to `domain.com/users` which results in a call to your frontend instead of your backend. The example you referenced solves a completely different issue, not the one we are talking about.

by CSDude 5y ago

herpderperator 5y ago

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...

CSDude 5y ago
I've just tried it. The following function works exactly as-is when the function is configured as Viewer request. I changed it to append some text to URL. See: https://github.com/aws-samples/amazon-cloudfront-functions/blob/main/url-rewrite-single-page-apps/index.js https://github.com/aws-samples/amazon-cloudfront-functions/b...
- herpderperator 5y ago
  That MODIFIES a viewer request, resulting in a viewer redirect. We want to keep the viewer request the same, i.e. with /api, and strip it only from the backend origin request. The viewer request is the one you make from the client, with /api. The origin request is the one CloudFront sends to your backend, which, without using Lambda@Edge via the origin request, will get sent as-is with the /api prefix. You have to strip it from the origin request. If you strip /api from the viewer request, your `domain.com/api/users` request becomes a redirect to `domain.com/users` which results in a call to your frontend instead of your backend. The example you referenced solves a completely different issue, not the one we are talking about.