web-dev-qa-db-ja.com

CloudFrontがS3ウェブサイトのリダイレクト場所を追跡しないのはなぜですか？

Amazon S3でホストされているウェブサイトがあります。 WordPressでホストされている古いウェブサイトの新しいバージョンです。

メタデータWebsite Redirect Locationを使用していくつかのファイルを設定し、古い場所を処理して、新しいWebサイトページにリダイレクトしました。

たとえば、http://www.mysite.com/solutionにリダイレクトしたいhttp://mysite.s3-website-us-east-1.amazonaws.com/product.htmlがあったため、バケット内にsolutionという名前の空のファイルを作成し、正しいメタデータを使用しました。

Website Redirect Location = /product.html

S3リダイレクトメタデータは、SEOに最適な301 Moved Permanentlyと同等です。これは、S3ドメインから直接URLにアクセスするときにうまく機能します。

また、ウェブサイトバケットに基づいてCloudFrontディストリビューションをセットアップしました。そして、私のディストリビューションを介してアクセスしようとすると、リダイレクトが機能しません。

http://xxxx123.cloudfront.net/solutionはリダイレクトせず、代わりに空のファイルをダウンロードします。

だから私の質問は、CloudFrontディストリビューションを通じてリダイレクトを維持する方法ですか？または、SEOを悪化させることなくリダイレ​​クトを処理する方法についてのアイデアはありますか？

ありがとう

amazon-s3amazon-cloudfront
21
Yannick Chaze

最近この問題に遭遇し、うまくいくように見える回避策を見つけました。

バケットのホスト名ではなく、S3静的ウェブサイトのホスト名を指すカスタムOriginを使用してCloudfrontディストリビューションを作成しました。 OPの場合、望ましいOriginは次のようになります。

mysite.s3-website-us-east-1.amazonaws.com

バケットをオリジンとして使用するだけでCloudfrontディストリビューションにアクセスしても、バケットは実際にはリダイレクトを提供しないため、機能しません。ファイルの提供とメタデータの保存のみを行います。

お役に立てば幸いです。

49
bmatsuo

分析

文書化された リクエストとレスポンスの動作、およびカスタムオリジンでサポートされているHTTPステータスコード によると、 Amazon CloudFront が従いません リダイレクト 、残念ながら：

[...]リダイレクトを構成した後、エンドユーザーがオブジェクトのリクエストを初めて送信すると、CloudFront FrontがリクエストをOriginに送信し、Originはリダイレクトで応答します（たとえば、302 Moved Temporarily）。 CloudFrontはリダイレクトをキャッシュし、エンドユーザーに返します。 CloudFrontがリダイレクトを追跡しません。[強調鉱山]

もちろん、カスタムOriginではなく Amazon S ​​を使用しており、関連セクションが Amazon S3 Originsのリクエストおよびレスポンス動作 に特にないが、Amazon S3リダイレクトが指定されているごく最近追加されたばかりです（ Amazon S3-ウェブサイトリダイレクトのサポート を参照）、まだそこにない場合があります。

したがって、HTTPステータスコード200 OKの空のファイルを受信せず、HTTPステータス301が永久に移動した本体なし-実際にこれをブラウザで確認したか、最終的にはコマンドラインツールだけで確認したか。 cURL または HTTPie ？後者のツールは通常、リダイレクトを追跡するために明示的なパラメーターを必要とするため、簡単に気付かない可能性があります。

可能な解決策

分析が正しいことが判明した場合は、代わりにCloudFrontを明示的にターゲットにするようにリダイレクトを構成する必要があります。再び Redirects を参照してください。

次のいずれかの場所にリクエストをリダイレクトするようにWebサーバーを構成できます。

  • オリジンサーバー上のオブジェクトの新しいURL。エンドユーザーが新しいURLへのリダイレクトに従うと、エンドユーザーはCloudFrontをバイパスして、直接Originに移動します。そのため、Origin上のオブジェクトの新しいURLにリクエストをリダイレクトしないことをお勧めします。

  • オブジェクトの新しいCloudFront URL。エンドユーザーが新しいCloudFront URLを含むリクエストを送信すると、CloudFrontはOriginの新しい場所からオブジェクトを取得し、それをEdgeの場所にキャッシュして、オブジェクトをエンドユーザーに返します。オブジェクトに対する後続のリクエストは、エッジロケーションによって処理されます。これにより、Originからオブジェクトをリクエストするビューアに関連する待ち時間と負荷が回避されます。ただし、オブジェクトの新しいリクエストごとに、CloudFrontへの2つのリクエストに対して料金が発生します。

2
Steffen Opel