CODEWITHSUNDEEP
amazon-web-servicesamazon-cloudfrontamazon-route53
Cleverson Schmidt
Cleverson Schmidt

Reputation: 53

Cloudfront not reached when integrated with Route 53

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!

Upvotes: 1

Views: 703

Answers (1)

Michael - sqlbot
Michael - sqlbot

Reputation: 179374

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.

Upvotes: 2

Related Questions