Google에서 개별 객체에 대한 S3에서 헤더를 설정할 수있는 몇 페이지를 쳤습니다. 내 경우에는 여러 객체에 대해 이야기하기 때문에 특별히 생산적으로 수행하는 방법은 아닙니다.
음, "생산적"인지 아닌지, 그것이 실제로 작동하도록 설계된 방식입니다.
CloudFront는 헤더를 추가 하지 않습니다 Cache-Control:
.
CloudFront를는 패스 스루 (그렇지 않는 구성도 존중)Cache-Control:
이 경우 S3 인 원 서버에 의해 제공되는 헤더.
Cache-Control:
객체를 가져올 때 S3에서 제공 한 헤더 를 가져 오려면 객체를 S3에 업로드하거나 후속 put + copy 작업을 통해 객체의 메타 데이터에 추가 할 때 제공해야합니다. 프로세스에서 메타 데이터를 수정하는 S3. 객체 메타 데이터를 편집 할 경우 콘솔이 배후에서 수행하는 작업입니다.
S3에는 버킷의 모든 객체가 이러한 헤더를 반환하도록 강제하는 전역 설정도 없습니다 (개체 별 속성).
업데이트 : Lambda @ Edge는 CloudFront의 새로운 기능으로, 요청 및 / 또는 응답, 뷰어와 캐시 및 / 또는 캐시와 오리진 사이에서 간단한 요청 / 응답 객체 구조에 대해 Node.js로 작성된 코드를 실행하여 트리거를 실행할 수 있습니다. CloudFront에 의해 노출됩니다.
이 기능의 주요 애플리케이션 중 하나는 헤더 조작입니다. 따라서 위의 내용은 여전히 정확하지만 CloudFront 자체는 추가되지 않습니다. Cache-Control
이제 Lambda 함수가 CloudFront에서 반환 된 응답에 헤더 를 추가 할 수 있습니다.
이 예제는 응답에 헤더 Cache-Control: public, max-age=86400
가없는 경우에만 추가 합니다 Cache-Control
.
오리진 응답 트리거에서이 코드를 사용하면 CloudFront가 오리진에서 객체를 가져올 때마다 실행되고 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 팀에 기능 요청을 제출했습니다 . 트위스트하여 각 헤더를 조건부로 추가하거나 (원점이 응답에서 해당 헤더를 제공하지 않은 경우에만) 조건부로 (헤더를 추가하고 헤더가있는 경우 헤더를 덮어 씁니다) 구성 할 수 있습니다.
기능 요청을 통해 일반적으로 실제로 새로운 기능 구현을 고려하고 있는지 또는 이미 기능을 수행했는지 여부에 대한 확인을받지 못합니다. 완료되면 바로 발표됩니다. 그래서, 이것이 구현 될지 모르겠습니다. Lambda @ Edge를 통해이 기능을 이미 사용할 수 있기 때문에 기본 기능에서이 기능이 필요하지 않다는 주장이 있습니다. 간단하고 정적 인 응답 헤더 조작을 수행해야하며, 이것이 트리거가 필요한 유일한 이유라면 Lambda 트리거를 요구하는 것은 재정적으로 추가 대기 시간이 걸리는 불필요한 비용입니다.