ChatGPT解决这个技术问题 Extra ChatGPT

Amazon S3 Redirect and Cloudfront

I'm trying to setup 301 redirects on S3 using objects, referenced here http://docs.aws.amazon.com/AmazonS3/latest/dev/how-to-page-redirect.html. I've been having some problems and can't seem to figure out what I'm doing wrong.

What I get is a blank page (0 byte file) as if the 'Website Redirect Location' metadata value is not set.

What am I doing wrong?

Also, does this work on AWS CloudFront?

https://i.stack.imgur.com/6JiN6.png

Couple things to note:

I have this setup for hosting a static site. I'm using ssl/https with my own cert uploaded and set on the cloudfront distribution. All the pages seem to work except the redirecting objects. I've tried setting up routing rules but they didn't seem to work in Cloudfront.

I'm trying to access the redirects both through the cloudfront url and the s3 url (https://s3.amazonaws.com/{bucket}/users/sign_in)


M
Michael - sqlbot

For web site-like functionality in S3, such as redirects, html error messages, and index documents, you can't use the REST endpoint (${bucket_name}.s3.amazonaws.com or ${bucket_name}.s3.${region}.amazonaws.com) since these features are only provided by the web site endpoints (${bucket_name}.s3-website.${region}.amazonaws.com).

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteEndpoints.html

To make the behavior available in Cloudfront, you need to configure Cloudfront to use this endpoint, as well, not the REST one offered via autocomplete in the console.

Enter the Amazon S3 static website hosting endpoint for your bucket. This value appears in the Amazon S3 console, on the Properties page under Static Website Hosting. When you specify the bucket name in this format, you can use Amazon S3 redirects and Amazon S3 custom error documents. http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/DownloadDistS3AndCustomOrigins.html

Note that the web endpoints do not support HTTPS, but you can configure Cloudfront to fetch from the bucket with HTTP even though the client connection is HTTPS.

Helpful tip: when troubleshooting and testing changes with CloudFront, users are often confused by the apparent "latency" between when you make changes and when CloudFront starts exhibiting the new behavior. In the case of error pages, CloudFront has a default 5 minute Error Caching Minimum TTL that prevents it from re-sending requests for failed pages to the origin, and this is a separate timer from the minimum/default/maximum TTL set in Cache Behavior. Particularly when testing, you may want to disable these timers and force a retry with each subsequent request of pages that returned errors, using the steps I provided in the answer to a question about apparent Amazon CloudFront Latency.


Do you have match viewer configured for your origin protocol policy? The s3 website endpoint does not support https. You will want to set it to http. docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/…
Thank you! After days of trying to figure out why i can't get it to work i finally found the right question and answer here :)
Here's something that got me stuck for ages. Be sure not to include S3OriginConfig param when you set the Origins and instead use CustomOriginConfig. Seems obvious but caught me out for a while :)
One additional thing to note is that if you were using a CloudFront OAI (Origin Access Identity) to restrict direct access to the S3 bucket, it won't work any more. An alternative (although it can be circumvented) is to create & forward a custom header, and have bucket policy that checks for it. e.g. abridge2devnull.com/posts/2018/01/…
@KJH that's true, OAIs don't work, because the web site hosting feature was only really intended to be used for publicly-readable content. Tweaking one of the few headers that S3 allows to be evaluated by policy is one of those things that's useful when the content only needs to be "secure" enough to keep honest people out. I've thought about creating a Lambda@Edge library to emulate the web endpoint functionality so this can all be avoided, but haven't found a sufficiently strong case for it yet.
K
Ken Shirriff

I had the same problem with redirects failing and zero-length files getting downloaded, but wasn't using Cloudfront.

The root cause in my case was my DNS CNAME record pointed to the REST endpoint (static.righto.com.s3-us-west-2.amazonaws.com) instead of the website endpoint (static.righto.com.s3-website-us-west-2.amazonaws.com). Updating the CNAME record fixed my redirects.

Another symptom of this problem was missing pages displayed an XML error page rather than an HTML error page.

This document explains the difference between website endpoints and REST endpoints.


O
Oleg Poltoratskii

If you come here to find solution without using CloudFront, here it is:

You can use s3cmd (in bash script, of course) and its parameters:

--add-header with x-amz-website-redirect-location

For example, this script solves problem for page /about/:

s3cmd \
--acl-public \
--add-header "x-amz-website-redirect-location: /about/" \
--no-preserve \
put "./path/to/any/small/file/at/your/local/drive/index.html" "s3://domain.com/about"

This script copy some existing file with new file name without trailing slash. It is not important what does file contain, because browser will be redirected immediately.

When you (and more important web-crawlers) try to open page /about you get 301 redirect to /about/. This allows to keep the right page in cache of google, yandex and other search engines.

You can repeat this code for several pages. Or you can add functionality for searching folders and make call for each one. Probably you will be so kind to show it here :)


This works also with CloudFront, just needs to have the bucket public so CF can connect.