8000 Fully qualified 301 redirects break Amazon CloudFront reverse proxy caching · Issue #29456 · symfony/symfony · GitHub
[go: up one dir, main page]
Skip to content

Fully qualified 301 redirects break Amazon CloudFront reverse proxy caching #29456

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.

Sign up for GitHub

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

Jump to bottom
Closed
arechsteiner opened this issue Dec 4, 2018 · 6 comments
Closed

Fully qualified 301 redirects break Amazon CloudFront reverse proxy caching #29456

arechsteiner opened this issue Dec 4, 2018 · 6 comments
Labels
Bug Routing Status: Needs Review Status: Waiting feedback Unconfirmed

Comments

@arechsteiner
Copy link
arechsteiner commented Dec 4, 2018 •
edited
Loading

Symfony version(s) affected: 4.2.0

Description
I am caching my Symfony based site through Amazon CloudFront, however I'm running into an issue with Symfony's way of redirecting using a fully qualified URL:

Both the function redirectToRoute("some_route") as well as the automatic trailing slash redirect introduced in 4.1 return a 301 response where the "Location" header includes the fully qualified URL instead of just the path.

This means that my "origin" Symfony application which runs under origin.mydomain.com will return a fully qualified redirect to https://origin.mydomain.com/some-route/.

So If someone comes along and requests an URL from mydomain.com/some-route they'll get redirected to https://origin.mydomain.com/some-route/ instead of /some-route/ which would then resolve to the correct host and protocol like so: https://mydomain.com/some-route/

The end result is that the user ends up on the URL of my origin server instead of being served by the CloudFront domain.

Since there is no mention of this in the docs under How to Configure Symfony to Work behind a Load Balancer or a Reverse Proxy I'm thinking it might be a bug.
@arechsteiner arechsteiner mentioned this issue Dec 4, 2018
Closed
@stof
Copy link
Member
stof commented Dec 4, 2018

Well, if the domain is not detected properly, it probably means that you haven't configured Amazon CloudFront as a trusted proxy (or not properly) and so Symfony does not know your request was for mydomain.com (it won't accept to trust proxy headers added by a non-trusted proxy)

@arechsteiner
Copy link
Author

For test purposes, I've tried to trust all proxies:

//public/index.php
//...
$request = Request::createFromGlobals();
echo $request->server->get('REMOTE_ADDR'); 
Request::setTrustedProxies(array('127.0.0.1', $request->server->get('REMOTE_ADDR')), Request::HEADER_X_FORWARDED_AWS_ELB); 
//...

I've tried with both the original HEADER_X_.. constant and the one in the snippet above. I'm facing all the same issues with this configuration.

Is there any way I could verify that Symfony trusts the CloudFront proxy now, in order to isolate the problem?

@stof
Copy link
Member
stof commented Dec 4, 2018

A quick google search seems to tell me that CloudFront is not setting the header for the forwarded host at all by default, and so that extra config is necessary to make it forward the host.

@xabbuh
Copy link
Member
xabbuh commented Dec 10, 2018

@arechsteiner Have you been able to check the CloudFront settings?

@arechsteiner arechsteiner reopened this Dec 10, 2018
@arechsteiner
Copy link
Author

I found the setting, but upon forwarding headers I ran into more issues where my origin server tried to redirect to some non-existent CGI script.

I decided to completely abandon the CloudFront reverse-proxy setup as it seems too much effort and I don't have that much traffic on my site. Also the thought of having to trust a multitude of probably changing IP addresses from CloudFront seemed daunting. Overall just too complex for my small operation.

I'm running the site normally now and currently this is not an issue for me anymore.

@xabbuh
Copy link
Member
xabbuh commented Dec 10, 2018

Thanks for the feedback. 👍 I close here then.

@xabbuh xabbuh closed this as completed Dec 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Bug Routing Status: Needs Review Status: Waiting feedback Unconfirmed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@stof @arechsteiner @xabbuh @carsonbot
0