Yesterday, I setup Certs and CloudFront, in order to move my sites from http to https. http auto-redirects to https. The CloudFront distros point at the S3 buckets. Everything works; except, some files are stuck in a redirect loop. I assumed it was CF being a bit slow, so I left it overnight. 12hrs later... same problem.
Examples:
https://www.humantruth.info/1.jpg -> Redirect loop. (20 redirects, then the browser gives up)
https://www.humantruth.info/bus_seats.jpg -> Loads fine.
In the S3 bucket, they both have 'Standard' Storage Class (whatever that means), and no sign of any special settings that are just on one of them but not the other.
I've tried different browsers on different devices at work and at home, and got the same results. I only change AWS settings once-every-few-years and have a very simple setup, and have never gone and tried to apply and particular forwarding or settings on individual images; I'm sure the settings for both are the same.
(Q1) What /kinds/ of things should I be doing to fault-find? I followed the AWS guides on "how to enable https", and left all settings default (as stated in the guide) except a few basic ones (such as setting the origins on the distros).
(Q2) Is it a caching problem? When I update S3 bucket items, the content on the live site is not updating, even 3hrs later. Normally, it updates within a minute. So I need to tell CF to update more frequently. Perhaps this is an obscure cause of the Redirect problem too.
Looking at https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/understanding-how-origin-request-policies-and-cache-policies-work-together.html , I'm tempted to update this setting:
CloudFront distribution > Edit Behaviour > Cache key and origin requests
From the default:
Cache policy and origin request policy (recommended)
To:
Legacy cache settings > None (for Headers, Query Strings and Cookies).
I don't use cookies at all, I don't do any kinds of special requests; the entire site is static .html pages, static .js, static .css and static image content.
(Q3) What is going on? I've got a really-very-simple setup, and complications like this make me think I ought to scrap the whole concept of https and just leave it http. Is something fundamentally wrong with CF and/or missing from the setup guides?
Fixed it. The solution:
After setting up CloudFront, do an Invalidate on /* files.
Amazon S3 buckets must ALREADY be using CloudFront by default, behind-the-scenes. When I created my own CloudFront distros, SOME files were already pre-cached when they existed just in http. So, when I implemented http > https forwarding, no matter what, SOME files were still being redirected by CloudFronts now-wrong pre-caches of old http versions.
So no matter what I done, they were never going to work (for a few files in particular), and it didn't matter what settings I had. The solution was, in CloudFront, to force an 'invalidation' of all files using the "everything" pattern, /*.
Very annoying that from inception before having done anything, it's default behaviour was that any already-cached files were going to make redirect-loops.
AWS really ought to include in their setup-guides for covnerting S3 sites from http to https, that this extra step is required to prevent this bug.