0
votes

I'm attempting to route my 'www.example.com' in S3 to 'example.com'. I'm using Amazon S3, Cloudfront, and Route 53.

When I visit 'www.example.com' console shows that I post two GETs (below), but I end up being redirected through 'http://www.example.com' to 'https://http//example.com.'

First GET Request:
- Host: www.example.com
- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) - Gecko/20100101 Firefox/56.0
- Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
- Accept-Language: en-US,en;q=0.5
- Accept-Encoding: gzip, deflate
- Connection: keep-alive
- Upgrade-Insecure-Requests: 1

First GET Response: - Content-Length: 0
- Date: Sun, 12 Nov 2017 04:47:31 GMT
- Location: http://https://example.com/
- Server: AmazonS3
- Age: 57072
- X-Cache: Hit from cloudfront
- Via: 1.1 **************************.cloudfront.net (CloudFront)
- X-Amz-Cf-Id: adKFULOwqXFzT9Q_SYjWsb-oCjcfBAmxUvk9iRl3kMo0hICMCmJJrA==

Second GET Request: - Host: https
- User-Agent: Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/56.0
- Accept: text/html,application/xhtml+xm…plication/xml;q=0.9,/;q=0.8
- Accept-Language: en-US,en;q=0.5
- Accept-Encoding: gzip, deflate
- Connection: keep-alive
- Upgrade-Insecure-Requests: 1

Second GET Response is never returned.

The error seems to start somewhere around the obviously incorrect response 'location' (italicized above). Then the second GET gets confused by the first GET's 'location' and sends the second GET to 'https' as the 'host', which results in a redirect to Google and the URL of 'https://http//example.com'. I confirm on Redirect Detective and Redirect Check that my redirect ends up at 'https://example.com' which really confuses me.

Any help is appreciated. I've tried a multitude of different things to try and fix it. I think I've finally narrowed it down some.

1
Invalidate /* in your CloudFront cache. You may have already fixed the problem but CloudFront is still returning a cached response, as evidenced by Age: 57072 and X-Cache: Hit from cloudfront. - Michael - sqlbot
I was able to resolve my issue without invalidating /*. I think I inadvertently created a 301 redirect loop because of one too many A records. I had an A and AAAA record for both 'www' and the naked domain. When I removed the 'www' AAAA record my issue resolved quickly. I'm going to try and post my answer for others when time permits. - John MacIntire
Interesting. AAAA is for IPv6. - John Hanley
I don't think one too many A records is the likely explanation. To support IPv4 and IPv6, you need both an A and an AAAA. More likely, this change may have routed your request to a different CloudFront edge where the old object wasn't cached. - Michael - sqlbot

1 Answers

0
votes

This means that the default document at www.johnmacintire.com (index.html, etc.) is returning the HTTP header: Location: http://https://example.com/. Notice how this is formatted incorrectly (http://https://).