HTTP 응답 헤더 지원

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

Apigee Edge 문서 보기

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

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

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

Cache-Control

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

Cache-Control 지원 제한

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

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

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

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

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

Cache-Control 지시문 Apigee에서 지시문을 처리하는 방법
cache-extension 지원되지 않음
max-age

ResponseCache 정책이 <UseResponseCacheHeaders> 요소를 true로 설정하면 이 지시문에서 지정한 시간(초) 동안 응답이 캐시될 수 있습니다.

이 지시문은 s-maxage 지시문에 의해 재정의되며 Expires 헤더를 재정의합니다. 정책의 <ExpirySettings> 요소로 재정의할 수도 있습니다. 자세한 내용은 응답 캐시 정책의 '캐시 항목 만료 설정'과 <UseResponseCacheHeaders>를 참조하세요.
must-revalidate 지원되지 않음 모든 캐시 항목은 만료되는 즉시 Apigee에서 삭제됩니다.
no-cache

Apigee는 원본 응답을 캐시하지만 후속 클라이언트 요청을 충족하는 데 사용되기 전에 원본 서버로 다시 검증해야 합니다. 이 규칙은 원본이 캐시로부터 반환되어야 함을 나타내기 위해 원본에서 304 Not Modified 응답을 반환하므로 전체 응답을 반환하는 데 필요한 처리를 저장합니다. 원본 서버가 전체 응답을 반환하면 기존 캐시 항목을 대체합니다. 이 지시문으로 지정된 모든 필드 이름은 무시됩니다.
no-store 지원되지 않음
no-transform 지원되지 않음
private 지원되지 않음 이 지시문이 수신되면 원본 응답은 캐시되지 않습니다. 모든 필드 이름은 무시됩니다.
proxy-revalidate 지원되지 않음 모든 캐시 항목은 만료되는 즉시 Apigee에서 삭제됩니다.
public 다른 지시문에서 다르게 표시하더라도 Apigee에서 원본 응답을 캐시합니다. HTTP/1.1 사양에 따라 응답에 승인 헤더가 포함된 경우만이 이 규칙의 유일한 예외입니다.
s-maxage

ResponseCache 정책이 <UseResponseCacheHeaders> 요소를 true로 설정하면 이 지시문에서 지정한 시간(초) 동안 응답이 캐시될 수 있습니다.

이 지시문은 max-age 지시문 및 Expires 헤더를 재정의합니다. 정책의 <ExpirySettings> 요소로 재정의할 수도 있습니다. 자세한 내용은 응답 캐시 정책의 '캐시 항목 만료 설정'과 <UseResponseCacheHeaders>를 참조하세요.

만료

ResponseCache 정책의 UseResponseCacheHeaders 플래그를 true로 설정하면 Apigee는 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를 사용하여 Apigee에 응답을 다시 보내면 Apigee는 응답과 함께 ETag를 캐시합니다.

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

If-Match

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

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

Apigee에서 If-Match 헤더를 포함하는 클라이언트로부터 인바운드 GET 요청을 받는 경우:

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

If-None-Match

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

Apigee에서 이 헤더와 함께 인바운드 GET 요청을 수신하는 경우:

If Then
If-None-Match 헤더는 하나 이상의 ETag를 지정합니다.
  1. Apigee는 지정된 URI의 만료되지 않은 캐시 항목을 검색하고 캐시된 항목의 모든 강력한 ETag를 If-None-Match 헤더에 지정된 항목과 비교합니다.
  2. 일치하는 항목이 확인되면 Apigee에서 304 Not Modified 상태를 반환합니다. 일치 항목이 없으면 Apigee에서 요청을 원본 서버로 전달합니다.

If-None-Match 헤더는 '*'를 지정하고 요청된 URI의 만료되지 않은 캐시된 항목이 존재합니다.

 Apigee에서 304 Not Modified 상태를 반환합니다.
동일한 요청 URI를 사용하는 캐시 항목이 발견되었지만 약한 ETag만 포함되어 있습니다. Apigee가 항목을 클라이언트에 반환하기 전에 원본 서버에서 항목을 다시 검증해야 합니다.
Apigee가 원본 서버에서 ETag를 수신합니다. ETag가 클라이언트에 변경되지 않은 상태로 반환됩니다.

If-Modified-Since

Apigee가 GET 요청으로 If-Modified-Since 헤더를 수신하면 유효한 캐시 항목이 존재하더라도 원본 서버로 전달됩니다.

이로써 Apigee를 통해 전달되지 않은 리소스에 대한 모든 업데이트가 반영됩니다. 원본 서버가 새 항목을 반환하면 Apigee에서 기존 캐시 항목을 새 값으로 바꿉니다. 서버가 304 Not Modified 상태를 반환하는 경우 캐시된 응답의 Last-Modified 헤더에서 변경되지 않았다고 표시되면 Apigee가 응답 값을 반환합니다.

Accept-Encoding

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

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