I'm trying to make Cloudfront work on my solution. I'm using Route 53 + CloudFront + ELB.
Consider the following:
1. Route 53 is pointing to CloudFront through a record set alias.
2. CloudFront is pointing to the ELB through a origin domain name.
3. CloudFront has an Alternate Domain Name set to my custom domain (mysite.com)
If I make a request using the CloudFront domain name (d1ngxxxx.cloudfront.net) or the custom domain (mysite.com), the initial request goes to CloudFront which responds with a HTTP 302. All the subsequent requests (for resources like images, css, js..) are made directly to the ELB domain name bypassing CloudFront.
What should I do to make all requests go throuhg CloudFront?
Thanks is advance!
I can't come up with a circumstance where Cloudfront would issue these redirects.
It seems likely that what's happening is that your server itself is issuing the 302 redirect, because it doesn't like the Host: header it's getting from Cloudfront.
Host: CloudFront sets the value to the domain name of the origin that is associated with the requested object.
— http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html
Cloudfront is then returning the redirect to the browser.
Cloudfront can also cache such a redirect, so be mindful of that as you're troubleshooting. The response headers should indicate whether cloudfront went to the origin for the particular reponse:
X-Cache: Miss from cloudfront
...or whether cloudfront served the request from cache.
X-Cache: Hit from cloudfront
Two possible approaches to resolve this:
If your legacy code is reacting to the Host: header in a negative way, you might be able to reconfigure the web server to modify that value before the code is able to see it, so the redirection wouldn't occur.
Alternately, you could use something outboard, a reverse-proxying engine like Varnish or HAProxy (of which I have touched on elsewhere). In HAProxy, for a simple example:
reqirep ^Host:\ .* Host:\ expected-domain.example.com if { hdr(host) -i unexpected-domain.example.com }
A rule in form similar to this would replace the Host: unexpected-domain.example.com header with Host: expected-domain.example.com in all incoming requests where that header was present, which should keep your legacy code happy and avoid the redirects. Running HAProxy in front of your legacy system doesn't impose a significant load, since the code is very tight. All of my legacy web systems are now fronted with these systems, to give me the ability to manipulate and modify behavior much more easily than might otherwise be possible.
Related
Hope you're all doing well!
I have a question I'm hoping to get some help with. I have a static site served through S3 with CloudFront distributions in front.
My main site is served on www.xyz.xyz and the cloudfront distribution connected ha a behavior http to https redirect.
Then I also want people to be able to access http://xyz.xyz, therefore I have created another bucket for the naked domain, with a redirect policy to www.xyz.xyz with http as protocol. In the CloudFront distribution connected to this the origin is the direct S3 website link, and not the bucket.
In the end this ensures all guests end at https://www.xyz.xyz, however when running Google Lighthouse for a SEO check, if I enter http://xyz.xyz it seems to go through 2 redirects, one to https and one to www and I'm assuming, according to Lighthouse, that this has some negative effects in that regard, both in terms of time to serve, but also SEO.
Am I doing something wrong? I hope you can help me. I really thought it was simpler, also with all the buckets and such :-)
I noticed in AWS Amplify you need to setup redirect/rewrites, but I guess in S3 + CloudFront terms, that's what I'm already doing.
Best,
To maintain compatibility with HSTS, you must perform your redirection in two steps. The first redirect should upgrade the request to https. The second can canonicalize the domain (add or remove www). So this behavior is desirable.
We would like to serve several test domains off a single S3 bucket using CloudFront as a frontend.
Namely, https://test-1.domain.com/index.html goes to bucket-1.s3.amazonaws.com/test-1/index.html, https://test-2.domain.com/index.html to bucket-1.s3.amazonaws.com/test-2/index.html and so on.
The problem is that our web app is an SPA, so when there is no content in the S3 bucket we should return 200 not 404, say https://test-2.domain.com/some/url should get bucket-1.s3.amazonaws.com/test-2/index.html without modifying an URL (thus, 302 is not an option).
It would be perfectly possible using an Error Pages setting for a CloudFront distribution if we were serving just a single domain, but we need to distinguish between test-1. and test-2. and use index.htmls from different subfolders. Is this still possible anyhow?
I think this is possible using Lambda#edge Origin request Function.
This is how I would do it in complicated way:
Whitelist HOST header (I know we shouldn't do it for S3)
Write a Lambda#edge function to read HOST header values and
if it test-1.domain.com, choose the Origin with path as
bucket-1.s3.amazonaws.com/test-1/ else bucket-1.s3.amazonaws.com/test-2/
https://aws.amazon.com/blogs/networking-and-content-delivery/dynamically-route-viewer-requests-to-any-origin-using-lambdaedge/
I have a domain from GoDaddy, with AWS Route53 for managing DNS records. Route53 sends request to a load-balancer.
For webserver I have a load-balancer that routes requests to a single (for now) EC2 instance and the nginx in EC2 instance get the request and sends a response to the client.
The problem is that when I use http:// to perform a request, AWS redirects requests to the https:// version of the domain with 307 Internal Redirect response. The response object has Non-Authoritative-Reason: HSTS header as well.
What's the problem and which component is redirected requests?
It's neither component.
This isn't anything from AWS... it's the browser. It's an internal redirect the browser is generating, related to HSTS... HTTP Strict Transport Security.
If you aren't doing it now, then presumably, in the past, you've generated a Strict-Transport-Security: header in responses from this domain, and the browser has remembered this fact, preventing you from accessing the site insecurely, as it is intended to do.
I know I'm lat eto the party but I wanted to post the actual full solution this this inspired from this post on the Wordpress forums.
Just removing the HSTS header from the server will not solve it because the browser cached the HSTS response and will continue triggering https:// for that website regardless. In Chrome/Chromium you can delete the website from about://net-internals/#hsts but that's hardly a solution for your visitors as you have no idea how many already cached it as HSTS.
On the server side, you need to set max-age=0 which will (as per the RFC) ask the browser to stop considering that host as HSTS.
In Apache, do the following:
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=0"
</IfModule>
and make sure you enabled the headers module (you can use a2enmod headers on Ubuntu/Debian/Mint).
Hi I have a dynamic application that has a search form. I'm trying to use CloudFront with a load balancer. When you do a search the application creates some URL parameters and reloads the page. For some reason cloudfront is doing a 302 redirect back to the origin. Does anybody know how to fix this?
I have the following configuration.
It's clear that you're going to want to turn on Forward Query Strings. Without it, cloudfront will treat the following urls as the same:
http://www.example.com
http://www.example.com?q=search_term
http://www.example.com?q=search_term&option=true
It's however not clear to me that this would result in 302 to the original url (btw. origin means something very specific when dealing with cloudfront/other cdns - it's often short for origin server which is the source behind the cdn)
The 302 redirect is much more likely to your Viewer Protocol Policy, which you have set http requests to redirect to http. You should double check that your application isn't reloading the http version of the page.
In what seems to be a very weird choice, Cloudfront sets the Host header to the origin server host that you specify when forwarding a request.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html
Why is this? More importantly, when using wildcard subdomains, how do I know which subdomain the request is from, when they all forward to the same origin?
Good news- cloudfront supports host header forwarding now. It's listed very deep in the documentation:
Host [header]: CloudFront sets the value to the domain name of the origin that is associated with the requested object.
Presumably, all you need to do is ensure header forwarding is enabled in the Default Cache Behavior Settings: