Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cyclic redirect with CloudFront #5

Closed
mister opened this issue Sep 25, 2019 · 5 comments
Closed

Cyclic redirect with CloudFront #5

mister opened this issue Sep 25, 2019 · 5 comments
Labels

Comments

@mister
Copy link

mister commented Sep 25, 2019

Hello,

The Lambda function is working well, but I have cyclic redirect when trying to configure it with CloudFront.

I created a CloudFront distribution with default settings and used S3's static website endpoint as the origin. Also, I used the CloudFront domain name for the URL Lambda envonment variable.

Existing images are served well. But for new images I receive redirects loop between API gateway and CloudFront. What is interesting, new image generated and accessible with S3's endpoint. Can't get what is wrong.

Any ideas on how to fix it?
Thank you.

@sagidM
Copy link
Owner

sagidM commented Sep 25, 2019

Thank you for issuing.
Unfortunately, I have not experienced CloudFront yet, but from what you have explained, the issue seems to be either on the CloudFront hand or in incorrectness of parameters.

If success, the lambda redirects to {URL}/{path}.

I would check the full url.
In your case, request to the full url redirects back to the lambda which causes a cycle.

You mentioned, a new image is generated and accessible.
Well, if you can open the generated image in your browser, then just make sure you are requesting the lambda with an appropriate path.

If this does not help, please let me know.
Also, specific examples might have clarified the case, e. g. the addresses of your lambda and CloudFront server (you may create temporary ones).

@mister
Copy link
Author

mister commented Sep 26, 2019

Hi @sagidM,

Lambda does redirect to the correct path, as you mentioned. For example, when a user visits
https://abcdefg.cloudfront.net/250xAUTO/f350fd70-b516-11e9-b57d-01a3c7a72c2d.jpg he will be redirected to API endpoint with 307 status, eg. https://myapi123.execute-api.us-east-1.amazonaws.com/prod. Once Lambda finished, the user redirected back to the initial URL with a 301 status code. At this point, a new image created and exists. But browser redirects back to API endpoint again.

What is interesting, the image becomes available through S3 website endpoint, but not through CDN. As far I understood after digging deeper, the issue related to CloudFront cache. It caches redirects. So, after the first redirect to API endpoint, CF caches destination URL and status code and does same action one next visit. On this case - when Lambda returns redirect path.

@sagidM
Copy link
Owner

sagidM commented Sep 26, 2019

If you request https://abcdefg.cloudfront.net/250xAUTO/f350fd70-b516-11e9-b57d-01a3c7a72c2d.jpg again in your browser, can you see the image?
If not, can you see it via a hard reload Ctrl+Shift+R?

@mister
Copy link
Author

mister commented Oct 1, 2019

No, browser redirects to API gateway again. The problem in CloudFront cache behavior (
https://docs.aws.amazon.com/en_us/AmazonCloudFront/latest/DeveloperGuide/http-3xx-status-codes.html)

Fixed by setting up CloudFlare distribution Cache Default TTL to 0 and added CacheControl to images created by Lambda:

...
.then(result =>
    S3.putObject({
        Body: result,
        Bucket: BUCKET,
        ContentType: contentType,
        Key: path,
        CacheControl: 'public, max-age=86400'
    }).promise()
)
...

@sagidM
Copy link
Owner

sagidM commented Oct 2, 2019

Cool, thank you for sharing.
Hope this helps others

@sagidM sagidM closed this as completed Oct 2, 2019
@sagidM sagidM mentioned this issue Nov 20, 2019
sagidM pushed a commit that referenced this issue Nov 20, 2019
There are 2 issues related to Cyclic redirect when using CloudFront
#5
#7
This commit adds the Cache-Control header to prevent that
@sagidM sagidM added the bug label Nov 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants