I'm using AWS CloudFront to host my web app from S3. Now, I'm changing the domain of my web app, let's say from foo.example.com to bar.example.com/foo.
In addition to setting up a new CloudFront distribution for bar.example.com that hosts the app, I also want to redirect users from foo.example.com to the new domain.
I've identified (at least) three ways of doing this:
- Host an index.html at foo.example.com, containing a good ol'
<meta http-equiv="refresh" content="0; url=https://bar.example.com/foo" />tag - Create a redirect rule for index.html in the S3 bucket containing the "old" app, pointing to the new URL
- Create a CloudFront viewer-request function that hijacks the requests before they're passed to the origin and instead returns a static HTTP 301 response pointing to the new location
Are any of these options superior to the others? If so, why?
Options 2 and 3 result in a HTTP 301 which makes the client go fetch the page at its new location. Option 1 however relies on a web browser parsing the http-equiv element and then fetch the page at its new location.
With my setup, the first one is slightly easier to implement - but is there any downside in not returning a proper HTTP 301 but instead relying on the browser to redirect on the client-side? I don't really care about SEO or any other potential programmatic access to my website, which might (?) be able to follow a 301 but not parse a <meta tag in HTML, I only care about the page being properly redirected in web browsers (however, examples of such problems are interesting, if nothing else for educational purposes).
