HTTP 응답 헤더 지원

현재 Apigee Edge 문서가 표시되고 있습니다.
Apigee X 문서로 이동 정보

이 주제에서는 ResponseCache 정책을 사용할 때 Edge에서 HTTP/1.1 캐싱 헤더를 처리하는 방법을 설명합니다. Apigee Edge는 현재 백엔드 대상 (원본) 서버에서 수신된 HTTP/1.1 캐싱 헤더 및 지시어 (이 주제에는 지원되지 않는 기능이 나열되어 있음)의 하위 집합을 지원합니다.

또한 특정 헤더의 경우 Edge는 지시어에 따라 작업을 수행합니다. 경우에 따라서는 ResponseCache 정책에 어떤 동작을 지정하든 이러한 HTTP/1.1 캐시 헤더가 이 동작을 재정의합니다. 예를 들어 백엔드 서버에서 Cache-Control 헤더가 반환되면 헤더의 s-maxage 지시문으로 정책의 다른 만료 설정을 재정의할 수 있습니다.

헤더	지원
Cache-Control	백엔드 원본 서버에서 반환되는 응답에 지원되며 클라이언트 요청에는 지원되지 않습니다. Edge는 지시어의 하위 집합을 지원합니다.
만료	지원됨 재정의 가능.
항목 태그(ETags)	If-Match 및 If-None-Match에 해당하는 특정 동작입니다.
If-Modified-Since	GET 요청의 경우 유효한 캐시 항목이 존재하더라도 헤더가 원본 서버로 전달됩니다.
Accept-Encoding	Edge는 수신 헤더에 따라 압축된 응답이나 압축되지 않은 응답을 전송합니다.

Cache-Control

Apigee Edge는 백엔드 원본 서버에서 반환된 응답에만 Cache-Control 헤더를 지원합니다. HTTP/1.1 사양은 클라이언트 요청과 원본 서버 응답에서 모두 Cache-Control 헤더를 허용합니다. 원본 서버에는 Apigee Edge API 프록시에 정의된 대상 엔드포인트와 TargetServer API 호출을 사용하여 만든 대상 엔드포인트가 모두 포함될 수 있습니다.

Cache-Control 지원 제한

Apigee Edge는 HTTP/1.1 사양에 정의된 Cache-Control 응답 헤더 기능의 하위 집합을 지원합니다. 다음에 유의하세요.

• Apigee Edge는 인바운드 클라이언트 요청과 함께 수신되는 Cache-Control 헤더를 지원하지 않습니다.
• Apigee Edge는 공개 캐시라는 개념만 지원합니다. (HTTP 사양에 따라 Cache-Control은 공개(공유) 또는 비공개(단일 사용자)일 수 있습니다.)
• Apigee Edge는 HTTP/1.1 사양에서 Cache-Control 응답 지시어 중 일부만 지원합니다. 자세한 내용은 Cache-Control 응답 헤더 지시문 지원을 참조하세요.

Cache-Control 응답 헤더 지시문 지원

Apigee에서 원본 서버의 응답에 HTTP/1.1 사양의 하위 집합 지시문을 지원합니다. 다음 표에서는 HTTP Cache-Control 응답 헤더 지시어에 대한 Apigee Edge 지원을 설명합니다.

여기 나열된 지시문에 대한 자세한 내용은 HTTP/1.1 사양의 Cache-Control을 참조하세요.

Cache-Control 지시문	Apigee Edge가 지시어를 처리하는 방법
cache-extension	지원되지 않음.
max-age	ResponseCache 정책이 <UseResponseCacheHeaders> 요소를 true로 설정하면 이 지시문에서 지정한 시간(초) 동안 응답이 캐시될 수 있습니다. 이 지시문은 s-maxage 지시문에 의해 재정의되며 Expires 헤더를 재정의합니다. 정책의 <ExpirySettings> 요소로 재정의할 수도 있습니다. 자세한 내용은 응답 캐시 정책의 '캐시 항목 만료 설정'과 <UseResponseCacheHeaders>를 참조하세요.
must-revalidate	지원되지 않음. 모든 캐시 항목은 만료되는 즉시 Apigee Edge에서 삭제됩니다.
no-cache	Edge는 원본 응답을 캐시하지만 후속 클라이언트 요청을 충족하는 데 사용하려면 원본 서버에서 유효성을 다시 검사해야 합니다. 이 규칙은 원본이 캐시로부터 반환되어야 함을 나타내기 위해 원본에서 304 Not Modified 응답을 반환하므로 전체 응답을 반환하는 데 필요한 처리를 저장합니다. 원본 서버가 전체 응답을 반환하면 기존 캐시 항목을 대체합니다. 이 지시문으로 지정된 모든 필드 이름은 무시됩니다.
no-store	지원되지 않음.
no-transform	지원되지 않음.
private	지원되지 않음. 이 지시문이 수신되면 원본 응답은 캐시되지 않습니다. 모든 필드 이름은 무시됩니다.
proxy-revalidate	지원되지 않음. 모든 캐시 항목은 만료되는 즉시 Apigee Edge에서 삭제됩니다.
public	Edge는 다른 지시문이 다르게 표시되더라도 원본 응답을 캐시합니다. HTTP/1.1 사양에 따라 응답에 승인 헤더가 포함된 경우만이 이 규칙의 유일한 예외입니다.
s-maxage	ResponseCache 정책이 <UseResponseCacheHeaders> 요소를 true로 설정하면 이 지시문에서 지정한 시간(초) 동안 응답이 캐시될 수 있습니다. 이 지시문은 max-age 지시문 및 Expires 헤더를 재정의합니다. 정책의 <ExpirySettings> 요소로 재정의할 수도 있습니다. 자세한 내용은 응답 캐시 정책의 '캐시 항목 만료 설정'과 <UseResponseCacheHeaders>를 참조하세요.

만료일

ResponseCache 정책의 UseResponseCacheHeaders 플래그를 true로 설정하면 Edge는 Expires 헤더를 사용하여 캐시된 항목의 TTL(수명)을 확인할 수 있습니다. 이 헤더는 응답의 캐시 항목이 오래된 것으로 간주되는 날짜/시간을 지정합니다. 이 헤더를 사용하면 타임스탬프를 토대로 캐시된 값을 반환할 수 있는 경우 서버에서 신호를 보내도록 할 수 있습니다.

Expires 헤더에 허용되는 날짜 형식은 HTTP/1.1 사양에 설명되어 있습니다. 예를 들면 다음과 같습니다.

만료: Thu, 01 Dec 1994 16:00:00 GMT

HTTP 날짜/시간 형식에 대한 자세한 내용은 HTTP/1.1 사양의 날짜/시간 형식을 참조하세요.

Expires 헤더에 대한 자세한 내용은 HTTP/1.1 사양의 헤더 필드 정의를 참조하세요.

ETag

항목 태그(ETag)는 요청된 리소스와 연결된 식별자입니다. ETag를 사용하면 서버는 요청된 리소스와 관련 캐시된 리소스가 일치하는지 확인할 수 있습니다. 예를 들어 현재 캐시된 항목과 일치하지 않는 경우 서버가 응답을 다시 캐시할 수 있습니다. ETag가 일치하면 캐시된 리소스를 반환할 수 있습니다.

대상 엔드포인트에서 ETag가 포함된 Edge로 응답을 다시 전송하면 Edge는 응답과 함께 ETag를 캐시합니다.

HTTP/1.1 사양의 프로토콜 매개변수에서 항목 태그에 대한 자세한 내용을 확인할 수 있습니다.

If-Match

If-Match 요청 헤더는 헤더의 ETag가 캐시된 ETag와 일치하는 경우 캐시된 항목이 최신 항목입니다. If-Match 헤더를 지정하는 GET 외의 요청은 모든 원본 캐싱 기능이 요청을 처리할 수 있도록 원본 서버로 전달됩니다.

If-Match에 대한 자세한 내용은 HTTP/1.1 사양의 헤더 필드 정의를 참조하세요.

Edge가 If-Match 헤더가 포함된 클라이언트로부터 인바운드 GET 요청을 받는 경우:

IF	Then
If-Match 헤더는 하나 이상의 ETag를 지정합니다.	Apigee Edge는 지정된 리소스의 만료되지 않은 캐시 항목을 검색하고 캐시된 항목의 강력한 ETag를 If-Match 헤더에 지정된 항목과 비교합니다. 일치하는 항목이 확인되면 캐시 항목이 반환됩니다. 일치 항목이 확인되지 않으면 요청이 원본 서버로 전달됩니다.
If-Match 헤더는 '*'를 지정합니다.	요청이 원본 서버로 전달되어 모든 원본 캐싱 기능이 요청을 처리할 수 있도록 합니다.
동일한 요청 URI를 사용하는 캐시 항목이 발견되었지만 약한 ETag만 포함되어 있습니다.	항목을 클라이언트에 반환하기 전에 원래 서버에서 유효성을 다시 검증해야 합니다.
ETag는 원본 서버에서 가져옵니다.	ETag가 클라이언트에 변경되지 않은 상태로 반환됩니다.

If-None-Match

If-None-Match 헤더는 헤더의 ETag가 캐시된 ETag와 일치하지 않는 경우 캐시된 항목이 최신 항목입니다. 이 헤더를 포함하는 GET 외의 요청은 원본 서버로 전달됩니다.

Edge에서 다음 헤더가 포함된 인바운드 GET 요청을 받는 경우:

IF	Then
If-None-Match 헤더는 하나 이상의 ETag를 지정합니다.	Apigee Edge는 지정된 URI의 만료되지 않은 캐시 항목을 검색하고 캐시된 항목의 강력한 ETag를 If-None-Match 헤더에 지정된 항목과 비교합니다. 일치하는 항목이 발견되면 Edge는 304 Not Modified 상태를 반환합니다. 일치하는 항목이 없으면 Edge가 요청을 원본 서버에 전달합니다.
If-None-Match 헤더는 '*'를 지정하고 요청된 URI의 만료되지 않은 캐시된 항목이 존재합니다.	Edge에서 304 Not Modified(수정되지 않음) 상태를 반환함
동일한 요청 URI를 사용하는 캐시 항목이 발견되었지만 약한 ETag만 포함되어 있습니다.	Edge가 클라이언트에 항목을 반환하기 전에 원본 서버에서 항목을 다시 검증해야 합니다.
Edge가 원본 서버에서 ETag를 수신함	ETag가 클라이언트에 변경되지 않은 상태로 반환됩니다.

If-Modified-Since

Apigee Edge가 GET 요청에서 If-Modified-Since 헤더를 수신하면 유효한 캐시 항목이 있어도 원본 서버에 전달됩니다.

이렇게 하면 Apigee Edge를 통과하지 못한 리소스의 모든 업데이트가 고려됩니다. 원본 서버가 새 항목을 반환하면 Edge는 기존 캐시 항목을 새 값으로 바꿉니다. 서버가 304 Not Modified 상태를 반환하는 경우, Edge는 캐시된 응답의 Last-Modified 헤더에 응답이 변경되지 않았다고 나타내면 응답 값을 반환합니다.

Accept-Encoding

수신된 요청에 gzip, deflate 또는 compress 값이 있는 Accept-Encoding 헤더가 포함되면 원본 서버에서 압축된 데이터로 응답합니다. 후속 요청이 Accept-Encoding 헤더 없이 수신되면 압축되지 않은 응답이 반환될 것으로 예상됩니다. Apigee의 응답 캐싱 메커니즘에서는 원본 서버로 돌아가지 않고도 수신 헤더에 따라 압축된 응답과 압축되지 않은 응답 모두를 전송할 수 있습니다.

캐시 키에 Accept 헤더 값을 추가하여 캐시된 각 항목에 키를 더 의미 있게 만들 수 있습니다. 자세한 내용은 응답 캐시 정책의 '캐시 키 구성'을 참조하세요.