Amazon AWSに移行しました。現在、正常に動作しているEC2インスタンスがあります。フロントエンドでNginxを、バックエンドでApacheを実行しています。それもうまくいっています。すべてのサイトが適切に起動され、EC2から提供されるファイルのCache-Controlヘッダーが含まれます。
問題は、Amazon S3に配置したすべての静的ファイルにあり、CloudFront CDN。ファイルには問題なくアクセスできます(CORSには問題はありません)が、明らかにCloudFrontはCache-Controlヘッダーを持つファイルを提供しません。ブラウザのキャッシュを活用します。
私が見るところ、静的ファイルはS3 + CloudFrontによって直接提供されているため、EC2インスタンスはここでは役割を果たしません。リクエストはEC2のWebサーバーに送信されません。
私は完全に迷子になっています。
質問:1)この場合、Cache-Controlを設定するにはどうすればよいですか? 2)キャッシュ制御を設定することは可能ですか? S3またはCloudFrontから?
注:Googleでいくつかのページにアクセスしました。S3のヘッダーを個々のオブジェクトに設定できます。私の場合、私たちはいくつかのオブジェクトについて話しているので、これは特別にそれを行うための生産的な方法ではありません。
ありがとう!
Googleでいくつかのページにアクセスしました。S3で個々のオブジェクトのヘッダーを設定できます。私の場合、私たちはいくつかのオブジェクトについて話しているので、これは特別にそれを行うための生産的な方法ではありません。
まあ、「生産的」かどうか、それが実際に機能するように設計されている方法です。
CloudFrontはCache-Control:
ヘッダーをaddしません。
CloudFrontpasses-through(また、特に構成されていない限り、尊重します)Cache-Control:
ヘッダーオリジンサーバーによって提供されます。この場合はS3です。
オブジェクトのフェッチ時にS3によって提供されるCache-Control:
ヘッダーを取得するには、オブジェクトがS3にアップロードされるときに提供されるか、内部のコピーに使用できる後続のput + copyオペレーションによってオブジェクトのメタデータに追加される必要がありますS3でオブジェクトをそれ自体に組み込み、プロセスのメタデータを変更します。これは、オブジェクトのメタデータを編集する場合に、コンソールが舞台裏で行うことです。
また、(ご参考までに)S3には、バケット内のすべてのオブジェクトがこれらのヘッダーを返すように強制するグローバル設定はありません。これはオブジェクトごとの属性です。
更新:Lambda @ EdgeはCloudFrontの新機能 リクエストやレスポンスに対してトリガーを起動できますCloudFrontによって公開された単純なリクエスト/レスポンスオブジェクト構造に対してNode.jsで記述されたコードを実行するビューアとキャッシュおよび/またはキャッシュとOrigin。
この機能の主なアプリケーションの1つはヘッダーの操作です...したがって、上記は依然として正確ですが、CloudFront自体はCache-Control
を追加しません-Lambda関数がそれらをレスポンスに追加できるようになりましたCloudFrontから返されます。
この例では、応答にCache-Control: public, max-age=86400
ヘッダーがすでに存在しない場合にのみCache-Control
を追加します。
このコードをOrigin Responseトリガーで使用すると、CloudFrontがOriginからオブジェクトをフェッチするたびに起動し、CloudFrontがキャッシュする前に応答を変更します。
'use strict';
exports.handler = (event, context, callback) => {
const response = event.Records[0].cf.response;
if(!response.headers['cache-control'])
{
response.headers['cache-control'] = [{
key: 'Cache-Control',
value: 'public, max-age=86400'
}];
}
callback(null, response);
};
更新(2018-06-20):最近、静的オリジンの構成を許可する機能リクエストをCloudFrontチームに送信しましたresponseヘッダーをOriginの属性として使用し、静的requestヘッダーを追加できるようになりましたが、今では...ひねりを加えて、各ヘッダーを構成できるようにしています条件付きで追加するか(Originが応答でそのヘッダーを提供しなかった場合のみ)、または無条件に追加します(ヘッダーを追加し、Originからのヘッダーを上書きします(存在する場合))。
機能のリクエストでは、通常、彼らが実際に新しい機能の実装を検討しているかどうか、またはすでに機能に取り組んでいるかどうかについての確認は届きません...完了時に通知されます。したがって、これらが実装されるかどうかはわかりません。この機能はすでにLambda @ Edgeを介して利用できるため、基本機能では必要ないという主張がありますが、私の反論は、基本的には機能が完全ではないため、単純で静的な応答ヘッダー操作を行います。これがトリガーが必要な唯一の理由である場合、Lambdaトリガーを要求することは不必要なコストであり、経済的にも待ち時間も長くなります(どちらも必ずしも異常なコストではありません)。