rfc7234: Hypertext Transfer Protocol (HTTP/1.1): Caching 에 대해 번역한 글입니다.
1. Introduction
HTTP는 일반적으로 분산 정보 시스템에 사용됩니다. 응답 캐시를 사용하여 성능을 향상시킬 수 있습니다. 이 문서는 응답 메시지 캐싱 및 재사용과 관련된 HTTP/1.1의 측면을 정의합니다.
글쓴이 메모: 분산 정보 시스템은 단일 컴퓨터에 위치하지 않고 컴퓨터 네트워크에 퍼져 있는 시스템입니다. 분산 정보 시스템에서는 여러 컴퓨터가 함께 작동하여 데이터와 리소스를 관리하고 공유합니다. 이를 통해 더 큰 확장성과 유연성은 물론 더 많은 양의 데이터 및 트랜잭션을 처리할 수 있습니다. HTTP는 분산 정보 시스템에서 널리 사용되는 통신 프로토콜이며 World Wide Web의 기반입니다.
HTTP 캐시는 응답 메시지의 로컬 저장소이자 그 안의 메시지 저장, 검색 및 삭제를 제어하는 하위 시스템입니다. 캐시는 향후 동등한 요청에 대한 응답 시간과 네트워크 대역폭 소비를 줄이기 위해 캐시 가능한 응답을 저장합니다. 모든 클라이언트 또는 서버는 캐시를 사용할 수 있지만(MAY) 터널 역할을 하는 서버에서는 캐시를 사용할 수 없습니다.
공유 캐시는 둘 이상의 사용자가 재사용할 응답을 저장하는 캐시입니다. 공유 캐시는 일반적으로(항상 그런 것은 아님) 중개자의 일부로 배포됩니다. 반대로 개인 캐시는 단일 사용자 전용입니다. 종종 사용자 에이전트의 구성 요소로 배포됩니다.
HTTP/1.1에서 캐싱의 목표는 현재 요청을 충족하기 위해 이전 응답 메시지를 재사용하여 성능을 크게 향상시키는 것입니다. 저장된 응답은 섹션 4.2에 정의된 대로 응답이 "유효성 검사(validation)"(캐싱된 응답이 이 요청에 대해 유효한지 확인하기 위해 원 서버와 확인) 없이 재사용할 수 있는 경우 "신선한(fresh)" 것으로 간주됩니다. 따라서 신선한 응답은 재사용될 때마다 대기 시간과 네트워크 오버헤드를 모두 줄일 수 있습니다. 캐시된 응답이 새롭지 않은 경우 유효성 검사를 통해 새로 고칠 수 있거나(섹션 4.3), 원본 서버를 사용할 수 없는 경우(섹션 4.2.4) 여전히 재사용할 수 있습니다.
글쓴이 메모: 원본 서버는 요청 중인 자원의 캐시되지 않은 버전의 원래 출처입니다. 즉, 자원의 마스터 복사본을 보유하고 있는 서버입니다.
1.1. 적합성 및 오류 처리 (Conformance and Error Handling)
이 문서에서 키워드 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" 및 "OPTIONAL"은 [RFC2119]에 설명된 대로 해석됩니다.
오류 처리에 관한 적합성 기준 및 고려 사항은 [RFC7230]의 섹션 2.5에 정의되어 있습니다.
1.2. Syntax Notation
이 사양은 [RFC7230]의 섹션 7에 정의된 확장된 목록에 있는 [RFC5234]의 ABNF(Augmented Backus-Naur Form) 표기법을 사용하여 '#' 연산자를 사용하여 쉼표로 구분된 목록의 압축 정의를 허용합니다('*' 연산자가 반복을 나타내는 방법과 비슷). 부록 B는 다른 문서에서 가져온 규칙에 대해 설명합니다. 부록 C는 표준 ABNF 표기법으로 확장된 모든 목록 연산자가 포함된 수집된 문법을 보여줍니다.
1.2.1. Delta Seconds
delta-seconds 규칙은 시간을 초 단위로 나타내는 음수가 아닌 정수를 지정합니다.
delta-seconds = 1*DIGIT델타초 값을 구문 분석하고 이진 형식으로 변환하는 수신자는 최소 31비트의 음수가 아닌 정수 범위의 산술 유형을 사용해야 합니다. 캐시가 나타낼 수 있는 가장 큰 정수보다 큰 델타 초 값을 수신하거나 후속 계산이 오버플로되는 경우 캐시는 값을 2147483648(2^31) 또는 편리하게 표현할 수 있는 가장 큰 양의 정수로 간주해야 합니다(MUST).
참고: 값 2147483648은 역사적인 이유로 여기에 있으며 사실상 무한대(68년 이상)를 나타내며 이진 형식으로 저장할 필요가 없습니다. 해당 숫자를 직접 표현할 수 없는 산술 형식으로 계산을 수행하더라도 오버플로가 발생하면 구현에서 미리 준비된 문자열로 생성할 수 있습니다. 여기서 중요한 것은 오버플로가 감지되고 이후 계산에서 음수 값으로 처리되지 않는다는 것입니다.
2. Overview of Cache Operation
적절한 캐시 작업은 HTTP 전송([RFC7231])의 의미 체계를 유지하면서 캐시에 이미 보관된 정보의 전송을 제거합니다. 캐싱은 전적으로 HTTP의 선택적 기능이지만 캐시된 응답을 재사용하는 것이 바람직하며 이러한 재사용은 요구 사항이나 로컬 구성이 금지하지 않는 경우 기본 동작이라고 가정할 수 있습니다. 따라서 HTTP 캐시 요구 사항은 캐시가 항상 특정 응답을 저장하고 재사용하도록 요구하기보다는 캐시가 재사용 불가능한 응답을 저장하거나 저장된 응답을 부적절하게 재사용하는 것을 방지하는 데 중점을 둡니다.
각 캐시 항목은 캐시 키와 동일한 키를 사용한 이전 요청에 해당하는 하나 이상의 HTTP 응답으로 구성됩니다. 캐시 항목의 가장 일반적인 형태는 검색 요청의 성공적인 결과입니다. 즉, GET 요청에 대한 200(OK) 응답으로, 요청 대상에 의해 식별된 리소스의 응답 내용(representation)을 포함합니다([RFC7231]의 섹션 4.3.1). 그러나 메소드의 정의가 캐싱을 허용하고 캐시 키로 사용하기에 적합한 것을 정의하는 경우, 영구적인 리다이렉션, 부정적인 결과(예: 404(Not Found)), 불완전한 결과(예: 206(Partial Content)) 및 GET 이외의 메서드에 대한 응답을 캐시할 수도 있습니다.
글쓴이 메모: HTTP에서 representation은 클라이언트의 요청에 대한 응답으로 반환되는 데이터 또는 정보를 나타냅니다. representation은 일반적으로 문서, 파일 또는 리소스 형식이며 텍스트, HTML, XML, JSON 또는 이진 데이터와 같은 다양한 형식으로 인코딩될 수 있습니다. representation에는 데이터의 특성과 형식을 설명하는 헤더 및 콘텐츠 유형 정보와 같은 메타데이터도 포함될 수 있습니다. 클라이언트는 요청의 "Accept" 헤더를 사용하여 원하는 표시 형식을 지정할 수 있습니다. 서버의 부하를 줄이고 성능을 향상시키기 위해 중개자가 representation을 캐시할 수도 있습니다.
기본 캐시 키는 요청 메서드와 대상 URI로 구성됩니다. 그러나 오늘날 일반적으로 사용되는 HTTP 캐시는 일반적으로 GET에 대한 응답 캐싱으로 제한되기 때문에 많은 캐시들은 단순히 다른 메서드들을 거부하고 URI만 기본 캐시 키로 사용합니다.
요청 대상이 콘텐츠 협상 대상인 경우 해당 캐시 항목은 원래 요청의 선택 헤더 필드 값에 대한 보조 키로 각각 구별되는 여러 개의 저장된 응답으로 구성될 수 있습니다(섹션 4.1).
3. Storing Responses in Caches
다음과 같은 경우를 제외하고 캐시는 요청에 대한 응답을 저장하면 안 됩니다(MUST NOT).
- 요청 메서드는 캐시에 의해 이해되고 캐시 가능한 것으로 정의되며,
- 응답 상태 코드는 캐시에서 이해하고
- "no-store" 캐시 지시어(섹션 5.2 참조)는 요청 또는 응답 헤더 필드에 나타나지 않으며,
- "private" 응답 지시어(섹션 5.2.2.6 참조)는 캐시가 공유되는 경우 응답에 나타나지 않으며,
- 승인 헤더 필드([RFC7235]의 섹션 4.2 참조)는 응답이 명시적으로 허용하지 않는 한(섹션 3.2 참조) 캐시가 공유되는 경우 요청에 나타나지 않습니다.
- 응답은 다음 중 하나입니다.
- Expires 헤더 필드(섹션 5.3 참조)를 포함하거나
- max-age 응답 지시문(섹션 5.2.2.8 참조)을 포함하거나
- s-maxage 응답 지시문(섹션 5.2.2.9 참조)을 포함하고 캐시가 공유되거나
- 캐시를 허용하는 캐시 제어 확장(섹션 5.2.3 참조)을 포함하거나
- 기본적으로 캐시 가능으로 정의된 상태 코드가 있는 경우(섹션 4.2.2 참조), 또는
- 공개 응답 지시문을 포함합니다(섹션 5.2.2.5 참조).
위에 나열된 모든 요구 사항은 cache-control extension에 의해 재정의될 수 있습니다. 섹션 5.2.3을 참조하십시오.
이 컨텍스트에서 캐시는 요청 메서드 또는 응답 상태 코드를 인식하고 지정된 모든 캐싱 관련 동작을 구현하는 경우 이를 "이해"한 것입니다.
정상적인 동작에서 일부 캐시는 캐시 유효성 검사기도 명시적 만료 시간도 없는 응답을 저장하지 않습니다. 이러한 응답은 일반적으로 저장하는 데 유용하지 않기 때문입니다. 그러나 캐시는 이러한 응답을 저장하는 것을 금지하지 않습니다.
3.1. Storing Incomplete Responses
연결이 닫히기 전에 메시지 프레이밍([RFC7230])이 나타내는 모든 옥텟이 수신되면 응답 메시지가 완료된 것으로 간주됩니다. 요청 메서드가 GET이고 응답 상태 코드가 200(OK)이고 전체 응답 헤더 섹션이 수신된 경우, 캐시 항목이 불완전한 것으로 기록되면 캐시는 불완전한 응답 메시지 본문을 저장할 수 있습니다(MAY). 마찬가지로 206(Partial Content) 응답은 불완전한 200(OK) 캐시 항목인 것처럼 저장될 수 있습니다(MAY). 그러나 캐시는 Range 및 Content-Range 헤더 필드를 지원하지 않거나 해당 필드에 사용된 범위 단위를 이해하지 못하는 경우 불완전하거나 부분적인 내용 응답을 저장하면 안 됩니다(MUST NOT).
캐시는 섹션 3.3에 정의된 대로 후속 범위 요청([RFC7233])을 만들고 저장된 항목과 성공적인 응답을 결합하여 저장된 불완전한 응답을 완료할 수 있습니다. 캐시는 응답이 완료되었거나 요청이 부분적이고 불완전한 응답 내에 있는 범위를 지정하지 않는 한 요청에 응답하기 위해 불완전한 응답을 사용해서는 안 됩니다(MUST NOT). 캐시는 206(Partial Content) 상태 코드를 사용하여 명시적으로 표시하지 않고 클라이언트에 부분 응답을 보내서는 안 됩니다(MUST NOT).
3.2. Storing Responses to Authenticated Requests
공유 캐시는 승인 헤더 필드([RFC7235]의 섹션 4.2)가 있는 요청에 대해 캐시된 응답을 사용해서는 안 되며(MUST NOT) 그러한 응답을 저장할 수 있도록 하는 캐시 지시문이 응답에 존재하지 않는 한 후속 요청을 만족시키기 위해 사용해서는 안 됩니다(MUST NOT).
이 사양에서 다음 Cache-Control 응답 지시어(섹션 5.2.2)는 must-revalidate, public 및 s-maxage와 같은 효과가 있습니다.
"must-revalidate" 및/또는 "s-maxage" 응답 지시문을 포함하는 캐시된 응답은 공유 캐시에서 오래된 것으로(섹션 4.2.4) 제공될 수 없습니다. 특히 "max-age=0, must-revalidate" 또는 "s-maxage=0" 응답은 원본 서버에서 재검증하지 않고 후속 요청을 충족하는 데 사용할 수 없습니다.
3.3. Combining Partial Content
연결이 너무 일찍 닫히거나 요청이 하나 이상의 범위 지정자를 사용한 경우 응답은 부분적인 응답 내용만 전송할 수 있습니다([RFC7233]). 이러한 여러 전송 후에 캐시는 동일한 응답 내용의 여러 범위를 수신했을 수 있습니다. 캐시는 이러한 범위를 단일 저장된 응답으로 결합할 수 있으며, 모두 동일한 강력한 검증자를 공유하고 캐시가 [RFC7233]의 섹션 4.3에 있는 클라이언트 요구 사항을 준수하는 경우 이후 요청을 충족하기 위해 해당 응답을 재사용할 수 있습니다(MAY).
새 응답을 하나 이상의 저장된 응답과 결합할 때 캐시는 다음을 충족해야 합니다.
- warn-code 1xx로 저장된 응답에서 Warning 헤더 필드를 삭제합니다(섹션 5.5 참조).
- warn-code 2xx를 사용하여 저장된 응답의 모든 경고 헤더 필드를 유지합니다. 그리고,
- Content-Range 외에 새 응답에 제공된 다른 헤더 필드를 사용하여 저장된 응답에서 해당 헤더 필드의 모든 인스턴스를 대체하십시오.
4. Constructing Responses from Caches
요청이 있을 때 캐시는 다음과 같은 경우가 아니면 저장된 응답을 재사용해서는 안 됩니다(MUST NOT).
- 제시된 유효한 요청 URI([RFC7230]의 Section 5.5)와 저장된 응답과 일치하는 URI, 그리고
- 저장된 응답과 관련된 요청 메서드는 제시된 요청에 사용할 수 있도록 허용하고,
- 저장된 응답(있는 경우)에 의해 지정된 헤더 필드를 선택하는 것은 제시된 것과 일치하고(섹션 4.1 참조),
- 제공된 요청은 저장된 응답이 성공적으로 검증되지 않는 한(섹션 4.3) no-cache pragma(섹션 5.4) 또는 no-cache 캐시 지시문(섹션 5.2.1)을 포함하지 않습니다. 그리고,
- 성공적으로 검증되지 않는 한(섹션 4.3), 저장된 응답은 no-cache 캐시 지시문(섹션 5.2.2.2)을 포함하지 않습니다. 그리고,
- 저장된 응답은 다음 중 하나입니다.
위에 나열된 모든 요구 사항은 cache-control extension에 의해 재정의될 수 있습니다. 섹션 5.2.3을 참조하십시오.
저장된 응답이 유효성 검사 없이 요청을 충족하는 데 사용되는 경우 캐시는 응답에 있는 모든 값을 저장된 응답의 current_age와 동일한 값으로 대체하여 Age 헤더 필드(섹션 5.1)를 생성해야 합니다(MUST). 섹션 4.2.3을 참조하십시오.
캐시는 안전하지 않은 메서드([RFC7231]의 섹션 4.2.1)를 사용하는 요청들을 통해 원본 서버에 작성해야 합니다(MUST). 즉, 캐시는 요청을 전달하고 해당 응답을 수신하기 전에 이러한 요청에 대한 응답을 생성할 수 없습니다.
또한 안전하지 않은 요청은 이미 저장된 응답을 무효화할 수 있습니다. 섹션 4.4를 참조하십시오.
둘 이상의 적절한 응답이 저장되면 캐시는 가장 최근 응답을 사용해야 합니다(Date 헤더 필드에 의해 결정됨)(MUST). 또한 "Cache-Control: max-age=0" 또는 "Cache-Control: no-cache"로 요청을 전달하여 사용할 응답을 명확하게 할 수 있습니다.
사용 가능한 시계가 없는 캐시는 사용할 때마다 재확인하지 않고 저장된 응답을 사용해서는 안 됩니다(MUST NOT).
4.1. Calculating Secondary Keys with Vary
캐시가 Vary 헤더 필드([RFC7231]의 섹션 7.1.4)가 있는 저장된 응답에 의해 충족될 수 있는 요청을 수신하면, Vary 헤더 필드에 의해 지정된 모든 선택 헤더 필드가 원래 요청(즉, 저장된 응답과 관련된 요청)과 제시된 요청 모두에서 일치하지 않는 한 해당 응답을 사용해서는 안 됩니다(MUST NOT).
두 요청의 선택 헤더 필드는 다음 중 하나를 적용하여 첫 번째 요청의 헤더 필드를 두 번째 요청의 헤더 필드로 변환할 수 있는 경우에만 일치하도록 정의됩니다.
- 헤더 필드의 구문에서 허용되는 경우, 공백 추가 또는 제거
- 여러 헤더 필드를 동일한 필드 이름으로 결합([RFC7230]의 섹션 3.2 참조)
- 헤더 필드의 명세에 따라 동일한 의미 체계를 갖는 것으로 알려진 방식으로 두 헤더 필드 값을 정규화(예: 순서가 중요하지 않은 경우 필드 값 재정렬, 값이 대소문자를 구분하지 않도록 정의된 대소문자 정규화)
(일어날 수 있는 모든 정규화 이후) 헤더 필드가 요청에 없는 경우, 다른 요청에도 헤더 필드가 없는 경우에만 다른 요청과 일치할 수 있습니다.
"*"의 Vary 헤더 필드 값은 항상 일치하지 않습니다.
일치하는 선택 헤더 필드가 있는 저장된 응답을 선택된 응답이라고 합니다.
선택한 응답이 여러 개 있는 경우(잠재적으로 Vary 헤더 필드가 없는 응답 포함) 캐시는 사용할 응답을 선택해야 합니다. 선택 헤더 필드에 알려진 메커니즘(예: Accept의 qvalues 및 유사한 요청 헤더 필드)이 있는 경우 해당 메커니즘을 사용하여 선호하는 응답을 선택할 수 있습니다(MAY). 나머지 중에서 섹션 4에 따라 가장 최근 응답(Date 헤더 필드에 의해 결정됨)이 사용됩니다.
선택한 응답을 사용할 수 없는 경우 캐시는 제시된 요청을 충족할 수 없습니다. 일반적으로 (아마도 조건부, 섹션 4.3 참조) 요청 시 원본 서버로 전달됩니다.
4.2. Freshness
신선한 응답(fresh response)은 나이(age)가 아직 신선도 수명을 초과하지 않은 것입니다. 반대로, 오래된 응답(stale response)은 응답이 있는 응답입니다.
응답의 신선도 수명은 원본 서버의 생성과 만료 시간 사이의 시간입니다. 명시적 만료 시간은 추가 유효성 검사 없이 캐시에서 저장된 응답을 더 이상 사용할 수 없도록 원본 서버가 의도하는 시간인 반면 휴리스틱 만료 시간은 명시적 만료 시간을 사용할 수 없을 때 캐시에서 할당합니다.
응답의 나이는 원본 서버에서 생성되었거나 원본 서버에서 성공적으로 검증된 이후 경과된 시간입니다.
응답이 캐시에서 "신선(fresh)"하면 원본 서버에 연결하지 않고도 후속 요청을 충족하는 데 사용할 수 있으므로 효율성이 향상됩니다.
신선도를 결정하는 기본 메커니즘은 Expires 헤더 필드(섹션 5.3) 또는 max-age 응답 지시문(섹션 5.2.2.8)을 사용하여 미래의 명시적인 만료 시간을 제공하는 원서버에 대한 것입니다. 일반적으로 원서버는 만료 시간에 도달하기 전에 응답 내용이 의미적으로 중요한 방식으로 변경되지 않을 것이라는 믿음으로 미래의 명시적 만료 시간을 응답에 할당합니다.
원서버가 캐시가 모든 요청의 유효성을 검사하도록 강제하려는 경우 응답이 이미 오래되었음을 나타내기 위해 과거의 명시적 만료 시간을 할당할 수 있습니다. 규정 준수 캐시(Compliant caches)는 일반적으로 후속 요청에 재사용하기 전에 오래된 캐시 응답의 유효성을 검사합니다(섹션 4.2.4 참조).
글쓴이 메모: 규정 준수 캐시(Compliant caches)는 데이터 캐싱 및 재사용을 위해 확립된 프로토콜 및 표준을 준수하는 캐시입니다. 이러한 프로토콜과 표준은 캐시된 데이터의 유효성을 검사하고 후속 요청에 재사용할 수 있는 시기를 결정하기 위한 규칙과 지침을 지정합니다. 예로는 HTTP 캐시와 DNS 캐시가 있습니다.
원서버가 항상 명시적인 만료 시간을 제공하지 않기 때문에 캐시는 특정 상황에서 만료 시간을 결정하기 위해 휴리스틱을 사용할 수도 있습니다(섹션 4.2.2 참조).
응답이 최신인지 확인하는 계산은 다음과 같습니다.
response_is_fresh = (freshness_lifetime > current_age)freshness_lifetime은 섹션 4.2.1에 정의되어 있습니다. current_age는 섹션 4.2.3에 정의되어 있습니다.
클라이언트는 해당 응답에 대한 신선도 계산을 제한하거나 완화하기 위해 요청에 max-age 또는 min-fresh 캐시 지시문을 보낼 수 있습니다(섹션 5.2.1).
신선도를 계산할 때 날짜 구문 분석의 일반적인 문제를 방지하려면 다음을 수행하십시오.
- 모든 날짜 형식이 대소문자를 구분하도록 지정되었지만 캐시 수신자는 대소문자를 구분하지 않고 일, 주 및 시간대 이름과 일치해야 합니다(SHOULD).
- HTTP-date 값보다 해당 캐시 수신자의 시간 해상도가 낮은 경우, 수신된 Expires 날짜를 가장 가까운 시간으로 표시해야 합니다.
- 캐시 수신자는 현지 표준 시간대가 수명 또는 만료 시간의 계산 또는 비교에 영향을 미치도록 허용해서는 안 됩니다(MUST NOT).
- 캐시 수신자는 GMT 또는 UTC 이외의 영역 약어가 있는 날짜를 만료 계산에 유효하지 않은 것으로 간주해야 합니다(SHOULD).
신선도는 캐시 작업에만 적용됩니다. 사용자 에이전트가 디스플레이를 새로 고치거나 리소스를 다시 로드하도록 강제하는 데 사용할 수 없습니다. 캐시와 기록 메커니즘의 차이점에 대한 설명은 섹션 6을 참조하십시오.
4.2.1. Calculating Freshness Lifetime
캐시는 다음의 첫 번째 일치 항목을 사용하여 응답의 신선도 수명(freshness_lifetime으로 표시됨)을 계산할 수 있습니다.
- 캐시가 공유되고 s-maxage 응답 지시문(섹션 5.2.2.9)이 있는 경우 해당 값을 사용하거나
- max-age 응답 지시문(섹션 5.2.2.8)이 있는 경우 해당 값을 사용하거나
- Expires 응답 헤더 필드(섹션 5.3)가 있는 경우 해당 값에서 Date 응답 헤더 필드 값을 뺀 값을 사용하거나
- 그렇지 않으면 응답에 명시적인 만료 시간이 없습니다. 휴리스틱 신선도 수명이 적용될 수 있습니다. 섹션 4.2.2를 참조하십시오.
이 계산은 시계 스큐(clock skew)에 노출되지 않는다는 점에 유의하십시오. 이유는 모든 정보가 원본 서버에서 제공되기 때문입니다.
글쓴이 메모: 클록 스큐는 둘 이상의 클록 간의 시간 차이를 나타냅니다. 컴퓨터 시스템에서 서로 다른 구성 요소 또는 장치의 클럭이 완벽하게 동기화되지 않은 경우 클럭 스큐가 발생할 수 있습니다. 이는 하드웨어 또는 소프트웨어 문제로 인해 또는 전원 공급 장치 또는 온도 변화로 인해 발생할 수 있습니다. 클록 스큐는 부정확한 타임스탬프, 메시지 전달 지연, 이벤트 순서 결정의 어려움과 같은 분산 시스템의 문제를 일으킬 수 있습니다.
주어진 지시어에 대해 둘 이상의 값이 있는 경우(예: 두 개의 Expires 헤더 필드, 여러 Cache-Control: max-age 지시어) 지시어의 값은 유효하지 않은 것으로 간주됩니다. 캐시는 유효하지 않은 신선도 정보가 있는 응답을 오래된 것으로 간주하도록 권장됩니다.
4.2.2. Calculating Heuristic Freshness
원서버가 항상 명시적인 만료 시간을 제공하는 것은 아니기 때문에 캐시는 명시적인 시간이 지정되지 않은 경우 휴리스틱 만료 시간을 할당할 수 있으며 그럴듯한 만료 시간을 추정하기 위해 다른 헤더 필드 값(예: Last-Modified 시간)을 사용하는 알고리즘을 사용합니다. 이 사양은 특정 알고리즘을 제공하지 않지만 결과에 대한 최악의 경우 제약 조건을 부과합니다.
캐시는 저장된 응답에 명시적인 만료 시간이 있을 때 신선도를 결정하기 위해 휴리스틱을 사용해서는 안 됩니다(MUST NOT). 섹션 3의 요구 사항으로 인해 이는 상태 코드가 기본적으로 캐시 가능한 것으로 정의된 명시적 신선도가 없는 응답([RFC7231]의 섹션 6.1 참조)에만 휴리스틱을 효과적으로 사용할 수 있음을 의미합니다. 명시적으로 캐시 가능한 것으로 표시되었습니다(예: "public" 응답 지시문 포함).
응답에 Last-Modified 헤더 필드([RFC7232]의 섹션 2.2)가 있는 경우 캐시는 해당 시간 이후 간격의 일부보다 크지 않은 휴리스틱 만료 값을 사용하도록 권장됩니다. 이 비율의 일반적인 설정은 10%일 수 있습니다.
신선도 수명을 계산하기 위해 휴리스틱을 사용하는 경우 캐시는 current_age가 24시간 이상이고 경고가 아직 존재하지 않는 경우 응답에 113 warn-code(섹션 5.5.4 참조)가 있는 Warning 헤더 필드를 생성해야 합니다(SHOULD).
참고: [RFC2616]의 섹션 13.9는 캐시가 쿼리 구성 요소(즉, '?'를 포함하는 것)가 있는 URI에 대한 휴리스틱 신선도를 계산하는 것을 금지했습니다. 실제로 이것은 널리 구현되지 않았습니다. 따라서 원본 서버는 캐싱을 방지하려면 명시적인 지시문(예: Cache-Control: no-cache)을 보내는 것이 좋습니다.
4.2.3. Calculating Age
Age 헤더 필드는 캐시에서 얻은 응답 메시지의 예상 수명을 전달하는 데 사용됩니다. Age 필드 값은 응답이 생성되거나 원본 서버에 의해 검증된 이후의 캐시 추정 시간(초)입니다. 본질적으로 Age 값은 응답이 원본 서버에서 경로를 따라 각 캐시에 상주한 시간과 네트워크 경로를 따라 전송된 시간의 합계입니다.
Age 계산에는 다음 데이터가 사용됩니다.
age_value
"age_value"라는 용어는 산술 연산에 적합한 형식으로 Age 헤더 필드(섹션 5.1)의 값을 나타냅니다. 또는 0(사용할 수 없는 경우).
date_value
"date_value"라는 용어는 산술 연산에 적합한 형식으로 Date 헤더 필드의 값을 나타냅니다. Date 헤더 필드의 정의와 이 필드가 없는 응답에 대한 요구 사항은 [RFC7231]의 섹션 7.1.1.2를 참조하십시오.
now
"now"라는 용어는 "계산을 수행하는 호스트에서 시계의 현재 값"을 의미합니다. 호스트는 NTP([RFC5905]) 또는 유사한 프로토콜을 사용하여 시계를 협정 세계시(Coordinated Universal Time)에 동기화해야 합니다.
request_time
요청이 저장된 응답을 생성한 시간에 호스트에 있는 시계의 현재 값입니다.
response_time
응답이 수신된 시간에 호스트의 시계 현재 값입니다.
응답 기간은 완전히 독립적인 두 가지 방법으로 계산할 수 있습니다.
- "apparent_age": response_time 빼기 date_value, 로컬 시계가 원본 서버의 시계와 적절하게 잘 동기화된 경우. 결과가 음수이면 결과가 0으로 대체됩니다.
- "corrected_age_value", 응답 경로를 따라 모든 캐시가 HTTP/1.1을 구현하는 경우. 캐시는 응답이 수신된 시간이 아니라 요청이 시작된 시간과 관련하여 이 값을 해석해야 합니다.
apparent_age = max(0, response_time - date_value);
response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;
이들은 다음과 같이 결합됩니다.
corrected_initial_age = max(apparent_age, corrected_age_value);캐시가 Age 헤더 필드의 값을 확신하지 않는 한(예: Via 헤더 필드에 HTTP/1.0 홉이 없기 때문에), 이 경우 corrected_age_value는 corrected_initial_age로 사용될 수 있습니다(MAY).
저장된 응답의 current_age는 저장된 응답이 원서버에서 마지막으로 검증된 이후의 시간(초)을 corrected_initial_age에 더하여 계산할 수 있습니다.
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;4.2.4. Serving Stale Responses
"오래된(stale)" 응답은 명시적 만료 정보가 있거나 휴리스틱 만료를 계산할 수 있지만 섹션 4.2의 계산에 따라 신선하지 않은 응답입니다.
캐시는 명시적인 프로토콜 내 지시문에 의해 금지된 경우 오래된 응답을 생성하면 안 됩니다(MUST NOT)(예: "no-store" 또는 "no-cache" 캐시 지시어, "must-revalidate" 캐시 응답 지시어, 또는 적용 가능한 "s-maxage" 또는 "proxy-revalidate" 캐시 응답 지시문(섹션 5.2.2 참조).
캐시는 연결이 끊기거나(즉, 원본 서버에 연결할 수 없거나 전달 경로를 찾을 수 없음) 명시적으로 허용되지 않는 한(예: max-stale 요청 지시문, 섹션 5.2.1 참조) 오래된 응답을 보내서는 안 됩니다(MUST NOT).
캐시는 오래된 응답에서 110 warn-code(섹션 5.5.1 참조)가 있는 Warning 헤더 필드를 생성해야 합니다(SHOULD). 마찬가지로, 캐시가 연결 해제된 경우 캐시는 오래된 응답에서 112 warn-code(섹션 5.5.3 참조)를 생성해야 합니다(SHOULD).
응답이 이미 오래된 경우에도 Age 헤더 필드가 없는 응답을 전달할 때 캐시는 새 Warning 헤더 필드를 생성하면 안 됩니다(SHOULD NOT). 캐시는 단순히 전송 중에 오래된 응답을 검증할 필요가 없습니다.
4.3. Validation
캐시에 요청된 URI에 대한 하나 이상의 저장된 응답이 있지만 그 중 어떤 것도 제공할 수 없는 경우(예: 캐시가 최신이 아니거나 선택할 수 없기 때문에, 섹션 4.1 참조), 전달된 요청에서 조건부 요청 메커니즘[RFC7232]을 사용하여 다음 인바운드 서버에 유효한 저장된 응답을 선택하여 프로세스에서 저장된 메타데이터를 업데이트하거나 저장된 응답을 새 응답으로 교체할 수 있는 기회를 제공합니다. 이 프로세스를 저장된 응답의 "유효성 검사(validating)" 또는 "재유효성 검사(revalidating)"라고 합니다.
4.3.1. Sending a Validation Request
캐시 유효성 검사를 위한 조건부 요청을 보낼 때 캐시는 저장된 응답의 유효성 검사기 메타데이터를 포함하는 하나 이상의 전제 조건 헤더 필드를 보낸 다음 수신자가 이를 비교하여 저장된 응답이 리소스의 현재 응답 내용과 동일한지 여부를 결정합니다.
이러한 유효성 검사기 중 하나는 응답의 유효성 검사를 위한 If-Modified-Since 헤더 필드 또는 응답 내용 선택을 위한 If-Unmodified-Since 또는 If-Range 헤더 필드에서 사용할 수 있는 Last-Modified 헤더 필드(RFC7232의 섹션 2.2)에 제공된 타임스탬프입니다(즉, 클라이언트는 해당 타임스탬프가 있는 이전에 얻은 응답 내용을 구체적으로 참조함).
또 다른 유효성 검사기는 ETag 헤더 필드([RFC7232]의 섹션 2.3)에 제공된 entity-tag입니다. 하나 이상의 저장된 응답을 나타내는 하나 이상의 entity-tag는 응답 유효성 검사를 위한 If-None-Match 헤더 필드 또는 응답 내용 선택을 위한 If-Match 또는 If-Range 헤더 필드에서 사용할 수 있습니다(즉, 클라이언트 나열된 entity-tag들을 사용하여 이전에 획득한 하나 이상의 응답 내용을 구체적으로 참조함).
4.3.2. Handling a Received Validation Request
요청 체인의 각 클라이언트는 자체 캐시를 가질 수 있으므로 중개자의 캐시가 다른(아웃바운드) 캐시에서 조건부 요청을 수신하는 것이 일반적입니다. 마찬가지로 일부 사용자 에이전트는 조건부 요청을 사용하여 데이터 전송을 최근 수정된 응답 내용으로 제한하거나 부분적으로 검색된 응답 내용의 전송을 완료합니다.
캐시가 저장된 200(OK) 또는 206(Partical Content) 응답 중 하나를 재사용하여 만족할 수 있는 요청을 수신하는 경우, 캐시는 선택한 응답에 포함된 해당 유효성 검사기와 관련하여 해당 요청에서 수신된 적용 가능한 조건부 헤더 필드 전제 조건을 평가해야 합니다(SHOULD). 캐시는 캐시된 응답으로 만족할 수 없는 의미 체계가 있는 요청에서 발견되거나 저장된 응답이 없는 대상 리소스에 적용되는 원서버에만 적용 가능한 조건부 헤더 필드를 평가해서는 안 됩니다(MUST NOT). 이러한 전제 조건은 일부 다른(인바운드) 서버를 위한 것일 수 있습니다.
캐시에 의한 조건부 요청의 적절한 평가는 [RFC7232]의 섹션 6에 정의된 대로 수신된 전제 조건 헤더 필드와 그 우선 순위에 따라 다릅니다. If-Match 및 If-Unmodified-Since 조건부 헤더 필드는 캐시에 적용할 수 없습니다.
If-None-Match 헤더 필드([RFC7232]의 섹션 3.2)를 포함하는 요청은 클라이언트가 캐시에 의해 선택된 저장된 응답과 비교하여 하나 이상의 자체 저장된 응답의 유효성을 검사하려고 함을 나타냅니다. 필드 값이 "*"이거나 필드 값이 entity-tag의 목록이고 그 중 적어도 하나가 선택한 저장된 응답의 entity-tag와 일치하는 경우, 캐시 수신자는 저장된 응답을 보내는 대신 304(Not Modified) 응답(선택한 저장된 응답의 메타데이터 사용)을 생성해야 합니다(SHOULD).
캐시가 엔터티 태그의 If-None-Match 목록을 포함하는 요청에 대해 자체 저장된 응답을 재검증하기로 결정하면 캐시는 수신된 목록을 자체 저장된 응답(신선하거나 오래된) 집합의 엔터티 태그 목록과 결합할 수 있습니다. 전달된 요청에서 대체 If-None-Match 헤더 필드 값으로 두 목록의 합집합을 보냅니다. 저장된 응답에 일부 내용만 포함된 경우 요청이 부분적으로 저장된 응답에 의해 완전히 충족되는 범위에 대한 것이 아닌 한 캐시는 합집합에 엔터티 태그를 포함해서는 안 됩니다(MUST NOT). 전달된 요청에 대한 응답이 304(Not Modified)이고 클라이언트 목록에 없는 엔터티 태그가 있는 ETag 헤더 필드 값이 있는 경우, 캐시는 304 응답 메타데이터(섹션 4.3.4)에 의해 업데이트된 해당 저장된 응답을 재사용하여 클라이언트에 대한 200(OK) 응답을 생성해야 합니다(MUST).
If-None-Match 헤더 필드가 없는 경우 If-Modified-Since 헤더 필드([RFC7232]의 섹션 3.3)를 포함하는 요청은 클라이언트가 수정 날짜까지 자체 저장된 응답 중 하나 이상을 검증하기를 원함을 나타냅니다. 캐시 수신자는 다음 경우 중 하나가 참인 경우 304(Not Modified) 응답(선택한 저장된 응답의 메타데이터 사용)을 생성해야 합니다(SHOULD). 1) 선택된 저장된 응답은 조건부 타임스탬프보다 이전이거나 동일한 Last-Modified 필드 값을 가지는 경우. 2) 선택한 저장된 응답에 Last-Modified 필드가 없지만 조건부 타임스탬프보다 이전이거나 같은 날짜 필드 값이 있는 경우. 또는, 3) 선택한 저장된 응답에 Last-Modified와 Date가 모두 존재하지 않지만 캐시는 조건부 타임스탬프보다 이전 또는 동일한 시간에 수신된 것으로 기록한 경우.
[RFC7233]에 정의된 대로 범위 요청에 대한 부분 응답을 구현하는 캐시는 선택한 저장된 응답과 관련하여 수신된 If-Range 헤더 필드([RFC7233]의 섹션 3.2)도 평가해야 합니다.
4.3.3. Handling a Validation Response
조건부 요청에 대한 응답의 캐시 처리는 상태 코드에 따라 다릅니다.
- 304(Not Modified) 응답 상태 코드는 저장된 응답을 업데이트하고 재사용할 수 있음을 나타냅니다. 섹션 4.3.4를 참조하십시오.
- 전체 응답(즉, 페이로드 본문이 있는 응답)은 조건부 요청에 지정된 저장된 응답 중 어느 것도 적합하지 않음을 나타냅니다. 대신 캐시는 요청을 만족시키기 위해 전체 응답을 사용해야 하며(MUST) 저장된 응답을 대체할 수 있습니다(MAY).
- 그러나 캐시가 응답 유효성 검사를 시도하는 동안 5xx(서버 오류) 응답을 수신하면, 이 응답을 요청 클라이언트에 전달하거나 서버가 응답하지 못한 것처럼 작동할 수 있습니다. 후자의 경우 캐시는 이전에 저장된 응답을 보낼 수 있습니다(MAY)(4.2.4절 참조).
4.3.4. Freshening Stored Responses upon Validation
캐시가 304(Not Modified) 응답을 수신하고 동일한 캐시 키에 대해 이미 하나 이상의 저장된 200(정상) 응답이 있는 경우, 캐시는 저장된 응답 중 이 새 응답으로 업데이트되는 응답을 식별한 다음 저장된 응답을 304 응답에 제공된 새로운 정보로 업데이트해야 합니다.
업데이트에 대한 저장된 응답은 다음 중 첫 번째 일치 항목(있는 경우)을 사용하여 식별됩니다.
- 새 응답에 강력한 유효성 검사기가 포함된 경우([RFC7232]의 섹션 2.1 참조) 해당 강력한 유효성 검사기가 업데이트를 위해 선택된 응답 내용을 식별합니다. 동일한 강력한 유효성 검사기로 저장된 모든 응답이 선택됩니다. 저장된 응답 중 동일한 강력한 검증자를 포함하지 않는 경우, 캐시는 저장된 응답을 업데이트하기 위해 새 응답을 사용해서는 안 됩니다(MUST NOT).
- 새 응답에 약한 유효성 검사기가 포함되어 있고 해당 유효성 검사기가 캐시의 저장된 응답 중 하나에 해당하는 경우 일치하는 저장된 응답 중 가장 최근 항목이 업데이트를 위해 선택됩니다.
- 새 응답에 유효성 검사기 형식이 포함되지 않고(예: 클라이언트가 Last-Modified 응답 헤더 필드 이외의 소스에서 If-Modified-Since 요청을 생성하는 경우) 저장된 응답이 하나만 있는 경우, 저장된 응답에도 유효성 검사기가 없으면 저장된 응답이 업데이트를 위해 선택됩니다.
업데이트를 위해 저장된 응답이 선택된 경우 캐시는 다음을 수행해야 합니다(MUST).
- warn-code 1xx로 저장된 응답에서 Warning 헤더 필드를 삭제합니다(섹션 5.5 참조).
- warn-code 2xx를 사용하여 저장된 응답의 모든 경고 헤더 필드를 유지합니다. 그리고,
- 304(Not Modified) 응답에 제공된 다른 헤더 필드를 사용하여 저장된 응답에서 해당 헤더 필드의 모든 인스턴스를 대체합니다.
4.3.5. Freshening Responses via HEAD
HEAD 메서드에 대한 응답은 본문이 없다는 점을 제외하면 GET을 사용한 동등한 요청과 동일합니다. HEAD 응답의 이 속성은 효율적인 조건부 GET 요청 메커니즘을 사용할 수 없는 경우(저장된 응답에 유효성 검사기가 없기 때문에)나 응답 내용의 본문이 변경되더라도 전송을 원하지 않는 경우 캐시된 GET 응답을 무효화하거나 업데이트 할 수 있도록 할 수 있습니다.
캐시가 주어진 요청 대상에 대한 인바운드 HEAD 요청을 만들고 200(OK) 응답을 수신하면, 캐시는 해당 요청에 대해 선택되었을 수 있는 저장된 각 GET 응답을 업데이트하거나 무효화해야 합니다(SHOULD)(섹션 4.1 참조).
선택할 수 있는 각 저장된 응답에 대해 저장된 응답과 HEAD 응답에 수신된 유효성 검사기 필드(ETag 및 Last-Modified)에 대해 일치하는 값이 있고 HEAD 응답에 Content-Length 헤더 필드가 있는 경우 값 Content-Length의 길이가 저장된 응답의 길이와 일치하는 경우 캐시는 아래 설명된 대로 저장된 응답을 업데이트해야 합니다(SHOULD). 그렇지 않으면 캐시는 저장된 응답이 오래된 것으로 간주해야 합니다(SHOULD).
캐시가 HEAD 응답에 제공된 메타데이터로 저장된 응답을 업데이트하는 경우 캐시는 다음을 충족해야 합니다(MUST).
- warn-code 1xx로 저장된 응답에서 Warning 헤더 필드를 삭제합니다(섹션 5.5 참조).
- warn-code 2xx를 사용하여 저장된 응답의 모든 Warning 헤더 필드를 유지합니다. 그리고,
- Cache-Control 헤더 필드에 의해 달리 제한되지 않는 한 HEAD 응답에 제공된 다른 헤더 필드를 사용하여 저장된 응답의 해당 헤더 필드의 모든 인스턴스를 교체하고 저장된 응답의 헤더 섹션에 새 헤더 필드를 추가합니다.
4.4. Invalidation
PUT, POST 또는 DELETE와 같은 안전하지 않은 요청 방법([RFC7231]의 섹션 4.2.1)은 원본 서버에서 상태를 변경할 가능성이 있으므로 중간/개입 캐시(intervening cache)는 이를 사용하여 콘텐츠를 최신 상태로 유지할 수 있습니다.
글쓴이 메모: 중간 캐시는 요청을 한 클라이언트와 원본 서버 사이에 존재하는 모든 캐시를 말합니다. 클라이언트가 서버에 요청을 하면 원본 서버에 도달하기 전에 요청이 하나 이상의 캐시를 통과할 수 있습니다. 이러한 캐시는 클라이언트와 원본 서버 사이에 있기 때문에 "intervening"으로 간주됩니다. 원본 서버의 응답은 클라이언트에 도달하기 전에 하나 이상의 캐시를 통과할 수도 있습니다. 중간 캐시는 자주 요청되는 리소스를 캐싱하고 재사용함으로써 원본 서버의 부하를 줄이고 전체 시스템의 성능을 향상시키는 데 도움이 될 수 있습니다. 그러나 오래된(stale) 데이터 또는 캐시 일관성 문제와 같은 문제가 발생할 수도 있습니다.
안전하지 않은 요청 방법에 대한 응답으로 오류가 아닌 상태 코드가 수신된 경우, 캐시는 유효 요청 URI([RFC7230]의 섹션 5.5)와 Location 및 Content-Location 응답 헤더 필드(존재하는 경우)의 URI를 무효화해야 합니다(MUST).
그러나 해당 URI의 호스트 부분이 유효한 요청 URI의 호스트 부분과 다른 경우 캐시는 Location 또는 Content-Location 응답 헤더 필드의 URI를 무효화해서는 안 됩니다(MUST NOT)([RFC7230]의 섹션 5.5). 이는 서비스 거부 공격(denial-of-service)을 방지하는 데 도움이 됩니다.
캐시는 안전성이 알려지지 않은 메서드로 요청에 대해 오류가 없는 응답을 수신할 때, 유효 요청 URI([RFC7230]의 섹션 5.5)를 무효화해야 합니다(MUST).
여기서 "non-error response"는 2xx(Successful) 또는 3xx(Redirection) 상태 코드가 있는 응답입니다. "Invalidate"는 캐시가 유효한 요청 URI와 관련된 모든 저장된 응답을 제거하거나 "invalid"으로 표시하고 후속 요청에 대한 응답으로 전송되기 전에 필수 유효성 검사가 필요함을 의미합니다.
모든 적절한 응답이 무효화된다는 보장은 없습니다. 예를 들어 상태 변경 요청은 통과하는 캐시의 응답을 무효화할 수 있지만 관련 응답은 아직 가지고 있지 않은 다른 캐시에 저장될 수 있습니다.
5. Header Field Definitions
이 섹션에서는 캐싱과 관련된 HTTP/1.1 헤더 필드의 구문 및 의미를 정의합니다.
5.1. Age
"Age" 헤더 필드는 응답이 생성되었거나 원본 서버에서 성공적으로 검증된 이후 보낸 사람의 추정 시간을 전달합니다. Age 값은 섹션 4.2.3에 지정된 대로 계산됩니다.
Age = delta-secondsAge 필드 값은 시간을 초 단위로 나타내는 음수가 아닌 정수입니다(섹션 1.2.1 참조).
Age 헤더 필드가 있다는 것은 이 요청에 대한 응답이 원본 서버에서 생성되거나 검증되지 않았음을 의미합니다. 그러나 Age 헤더 필드가 없다고 해서 원본 서버에 연결되었다는 의미는 아닙니다. 응답이 Age를 구현하지 않는 HTTP/1.0 캐시에서 수신되었을 수 있기 때문입니다.
5.2. Cache-Control
"Cache-Control" 헤더 필드는 요청/응답 체인을 따라 캐시에 대한 지시문을 지정하는 데 사용됩니다. 이러한 캐시 지시어는 요청에 지시어가 있다고 해서 동일한 지시어가 응답에 제공된다는 것을 의미하지 않는다는 점에서 단방향입니다.
캐시는 이 섹션에 정의된 Cache-Control 지시문의 요구 사항을 준수해야 합니다(MUST). 다른 곳에서 정의된 Cache-Control 지시문을 처리하는 방법에 대한 정보는 섹션 5.2.3을 참조하십시오.
참고: 일부 HTTP/1.0 캐시는 Cache-Control을 구현하지 않을 수 있습니다.
프록시는 캐시를 구현하는지 여부에 관계없이 지시문이 요청/응답 체인을 따라 모든 수신자에게 적용될 수 있기 때문에 해당 응용 프로그램에 대한 중요도에 관계없이 전달된 메시지에서 캐시 지시문을 통과해야 합니다. 지시문을 특정 캐시로 지정하는 것은 불가능합니다. 캐시 지시문은 토큰으로 식별되며 대소문자를 구분하지 않고 비교되며 토큰과 인용 문자열 구문을 모두 사용할 수 있는 선택적 인수가 있습니다. 인수를 정의하는 아래에 정의된 지시문의 경우 수신자는 하나가 선호되는 것으로 문서화되어 있더라도 두 형식을 모두 수락해야 합니다. 이 사양에 의해 정의되지 않은 지시어의 경우, 수신자는 두 형식을 모두 수락해야 합니다(MUST).
Cache-Control = 1#cache-directive
cache-directive = token [ "=" ( token / quoted-string ) ]아래에 정의된 캐시 지시문의 경우 달리 명시되지 않는 한 인수가 정의되거나 허용되지 않습니다.
5.2.1. Request Cache-Control Directives
5.2.1.1. max-age
인수 구문:
delta-seconds (섹션 1.2.1 참조)
"max-age" 요청 지시문은 클라이언트가 지정된 시간(초)보다 오래된 응답을 수락하지 않음을 나타냅니다. max-stale 요청 지시문도 존재하지 않는 한 클라이언트는 오래된 응답을 수락하지 않습니다.
이 지시문은 인수 구문의 토큰 형식을 사용합니다. 예를 들어 'max-age="5"'가 아닌 'max-age=5'입니다. 발신자는 quoted-string 형식을 생성하면 안 됩니다(SHOULD NOT).
5.2.1.2. max-stale
인수 구문:
delta-seconds (섹션 1.2.1 참조)
"max-stale" 요청 지시문은 클라이언트가 신선도 수명을 초과한 응답을 수락할 용의가 있음을 나타냅니다. max-stale에 값이 할당된 경우 클라이언트는 지정된 시간(초) 이하로 신선도 수명을 초과한 응답을 기꺼이 수락합니다. max-stale에 값이 지정되지 않은 경우 클라이언트는 모든 Age의 오래된 응답을 기꺼이 수락합니다.
이 지시문은 인수 구문의 토큰 형식을 사용합니다. 예를 들어 'max-stale="10"'가 아닌 'max-stale=10'입니다. 발신자는 quoted-string 형식을 생성하면 안 됩니다(SHOULD NOT).
5.2.1.3. min-fresh
인수 구문:
delta-seconds (섹션 1.2.1 참조)
"min-fresh" 요청 지시문은 클라이언트가 신선도 수명이 현재 수명에 지정된 시간(초)을 더한 것보다 작지 않은 응답을 수락할 의향이 있음을 나타냅니다. 즉, 클라이언트는 최소한 지정된 시간(초) 동안 여전히 신선한 응답을 원합니다.
이 지시문은 인수 구문의 토큰 형식을 사용합니다. 예를 들어 'min-fresh="20"'이 아닌 'min-fresh=20'입니다. 발신자는 quoted-string 형식을 생성하면 안 됩니다(SHOULD NOT).
5.2.1.4. no-cache
"no-cache" 요청 지시어는 캐시가 원서버에서 성공적인 검증 없이 요청을 만족시키기 위해 저장된 응답을 사용해서는 안 된다는 것을 나타냅니다(MUST NOT).
5.2.1.5. no-store
"no-store" 요청 지시어는 캐시가 이 요청 또는 이에 대한 응답의 어떤 부분도 저장해서는 안 된다는 것을 나타냅니다(MUST NOT). 이 지시문은 개인 및 공유 캐시 모두에 적용됩니다. 이 문맥에서 "저장해서는 안된다는 것"은 캐시가 정보를 비휘발성 저장소에 의도적으로 저장해서는 안 되며, 정보를 전달한 후 가능한 한 신속하게 휘발성 저장소에서 정보를 제거하기 위해 최선을 다해야 함을 의미합니다(MUST NOT).
이 지침은 프라이버시를 보장하기 위한 신뢰할 수 있거나 충분한 메커니즘이 아닙니다. 특히 악의적이거나 손상된 캐시는 이 지침을 인식하거나 따르지 않을 수 있으며 통신 네트워크는 도청에 취약할 수 있습니다.
이 지시문을 포함하는 요청이 캐시에서 충족되면 no-store 요청 지시문은 이미 저장된 응답에 적용되지 않습니다.
5.2.1.6. no-transform
"no-transform" 요청 지시어는 [RFC7230]의 섹션 5.7.2에 정의된 대로 중개자(캐시를 구현하는지 여부에 관계없이)가 페이로드를 변환하지 않아야 함을 나타냅니다(MUST NOT).
5.2.1.7. only-if-cached
"only-of-cached" 요청 지시문은 클라이언트가 저장된 응답만 얻기를 원한다는 것을 나타냅니다. 이 지시문을 받으면 캐시는 요청의 다른 제약 조건과 일치하는 저장된 응답을 사용하여 응답하거나 504(게이트웨이 시간 초과) 상태 코드로 응답해야 합니다(SHOULD). 캐시 그룹이 내부 연결성이 좋은 통합 시스템으로 작동하는 경우 구성원 캐시는 해당 캐시 그룹 내에서 그러한 요청을 전달할 수 있습니다.
5.2.2. Response Cache-Control Directives
5.2.2.1. must-revalidate
"must-revalidate" 응답 지시문은 캐시가 오래되면 캐시가 원서버에서 성공적인 유효성 검사 없이 후속 요청을 충족하기 위해 응답을 사용해서는 안 됨을 나타냅니다.
must-revalidate 지시문은 특정 프로토콜 기능에 대한 안정적인 작동을 지원하는 데 필요합니다. 모든 상황에서 캐시는 must-revalidate 지시어를 따라야 합니다. 특히 캐시가 어떤 이유로든 원본 서버에 도달할 수 없는 경우 504(Gateway Timeout) 응답을 생성해야 합니다.
must-revalidate 지시문은 응답 내용에 대한 요청의 유효성을 검사하지 않으면 자동으로 실행되지 않는 금융 거래와 같이 잘못된 작업이 발생할 수 있는 경우에만 서버에서 사용해야 합니다.
5.2.2.2. no-cache
인수 구문:
#field-name
"no-cache" 응답 지시어는 응답이 원서버에서 성공적인 검증 없이 후속 요청을 만족시키는 데 사용되어서는 안 된다는 것을 나타냅니다(MUST NOT). 이를 통해 원본 서버는 오래된 응답을 보내도록 구성된 캐시에서도 캐시에 접속하지 않고 요청을 충족하기 위해 캐시를 사용하는 것을 방지할 수 있습니다.
no-cache 응답 지시문이 하나 이상의 필드 이름을 지정하는 경우 캐시는 캐싱에 대한 다른 제한 사항에 따라 후속 요청을 충족하기 위해 응답을 사용할 수 있습니다(MAY). 그러나 필드 이름이 나열된 응답의 모든 헤더 필드는 원서버와의 성공적인 재검증 없이 후속 요청에 대한 응답으로 보내서는 안 됩니다(MUST NOT). 이를 통해 원서버는 나머지 응답의 캐싱을 허용하면서 응답에서 특정 헤더 필드의 재사용을 방지할 수 있습니다.
주어진 필드 이름은 이 사양에서 정의한 헤더 필드 집합으로 제한되지 않습니다. 필드 이름은 대소문자를 구분하지 않습니다.
이 지시문은 인수 구문의 인용 문자열 형식을 사용합니다. 발신자는 토큰 양식을 생성하면 안 됩니다(SHOULD NOT)(단일 항목 목록에 인용이 필요하지 않은 것처럼 보이더라도).
참고: 많은 구현으로 백포팅되었지만 일부 HTTP/1.0 캐시는 이 지시문을 인식하거나 따르지 않습니다. 또한 필드 이름이 있는 no-cache 응답 지시문은 종종 규정되지 않은 no-cache 지시문이 수신된 것처럼 캐시에 의해 처리됩니다. 즉, 한정된 형식에 대한 특수 처리가 널리 구현되지 않습니다.
5.2.2.3. no-store
"no-store" 요청 지시어는 캐시가 이 요청 또는 이에 대한 응답의 어떤 부분도 저장해서는 안 된다는 것을 나타냅니다(MUST NOT). 이 지시문은 개인 및 공유 캐시 모두에 적용됩니다. 이 문맥에서 "저장해서는 안된다는 것"은 캐시가 정보를 비휘발성 저장소에 의도적으로 저장해서는 안 되며, 정보를 전달한 후 가능한 한 신속하게 휘발성 저장소에서 정보를 제거하기 위해 최선을 다해야 함을 의미합니다(MUST NOT).
이 지침은 프라이버시를 보장하기 위한 신뢰할 수 있거나 충분한 메커니즘이 아닙니다. 특히 악의적이거나 손상된 캐시는 이 지침을 인식하거나 따르지 않을 수 있으며 통신 네트워크는 도청에 취약할 수 있습니다.
5.2.2.4. no-transform
"no-transform" 요청 지시어는 [RFC7230]의 섹션 5.7.2에 정의된 대로 중개자(캐시를 구현하는지 여부에 관계없이)가 페이로드를 변환하지 않아야 함을 나타냅니다(MUST NOT).
5.2.2.5. public
"public" 응답 지시문은 응답이 일반적으로 캐시 불가능하거나 개인 캐시 내에서만 캐시 가능하더라도 모든 캐시가 응답을 저장할 수 있음을 나타냅니다.(MAY)(Authorization이 포함된 요청에 대한 응답으로 public 사용과 관련된 추가 세부 정보는 섹션 3.2를 참조하고 기본적으로 캐시 가능한 것으로 정의되지 않은 상태 코드로 인해 일반적으로 저장되지 않는 응답에 public이 어떻게 영향을 미치는지에 대한 자세한 내용은 섹션 3을 참조하십시오. 섹션 4.2.2 참조)
5.2.2.6. private
인수 구문:
#field-name
"private" 응답 지시문은 응답 메시지가 단일 사용자를 위한 것이며 공유 캐시에 저장되어서는 안 된다는 것을 나타냅니다. 개인 캐시는 응답을 저장하고 응답을 일반적으로 캐시할 수 없는 경우에도 이후 요청에 재사용할 수 있습니다(MAY).
비공개 응답 지시문이 하나 이상의 필드 이름을 지정하는 경우 이 요구 사항은 나열된 응답 헤더 필드와 연결된 필드 값으로 제한됩니다. 즉, 공유 캐시는 지정된 필드 이름을 저장하면 안 되며(MUST NOT) 응답 메시지의 나머지 부분을 저장할 수 있습니다(MAY).
주어진 필드 이름은 이 사양에서 정의한 헤더 필드 집합으로 제한되지 않습니다. 필드 이름은 대소문자를 구분하지 않습니다.
이 지시문은 인수 구문의 quoted-string 형식을 사용합니다. 발신자는 토큰 형식을 생성하면 안 됩니다(SHOULD NOT)(단일 항목 목록에 인용이 필요하지 않은 것처럼 보이더라도).
참고: "private"라는 단어의 사용은 응답을 저장할 수 있는 위치만 제어합니다. 메시지 내용의 프라이버시를 보장할 수 없습니다. 또한 필드 이름이 있는 개인 응답 지시문은 종종 정규화되지 않은 개인 지시문이 수신된 것처럼 캐시에 의해 처리됩니다. 즉, 한정된 형식에 대한 특수 처리가 널리 구현되지 않습니다.
5.2.2.7. proxy-revalidate
"proxy-revalidate" 응답 지시문은 개인 캐시에 적용되지 않는다는 점을 제외하면 must-revalidate 응답 지시문과 동일한 의미를 갖습니다.
5.2.2.8. max-age
인수 구문:
delta-seconds (섹션 1.2.1 참조)
"max-age" 요청 지시문은 클라이언트가 지정된 시간(초)보다 오래된 응답을 수락하지 않음을 나타냅니다. max-stale 요청 지시문도 존재하지 않는 한 클라이언트는 오래된 응답을 수락하지 않습니다.
이 지시문은 인수 구문의 토큰 형식을 사용합니다. 예를 들어 'max-age="5"'가 아닌 'max-age=5'입니다. 발신자는 quoted-string 형식을 생성하면 안 됩니다(SHOULD NOT).
5.2.2.9. s-maxage
인수 구문:
delta-seconds (섹션 1.2.1 참조)
"s-maxage" 응답 지시문은 공유 캐시에서 이 지시문에 의해 지정된 최대 수명이 max-age 지시문 또는 Expires 헤더 필드에 의해 지정된 최대 수명보다 우선함을 나타냅니다. s-maxage 지시문은 또한 프록시 재검증 응답 지시문의 의미 체계를 의미합니다.
이 지시문은 인수 구문의 토큰 형식을 사용합니다. 예를 들어 's-maxage="10"'가 아닌 's-maxage=10'입니다. 발신자는 quoted-string 형식을 생성하면 안 됩니다(SHOULD NOT).
5.2.3. Cache Control Extensions
Cache-Control 헤더 필드는 각각 선택적 값이 있는 하나 이상의 캐시 확장 토큰을 사용하여 확장할 수 있습니다. 캐시는 인식되지 않은 캐시 지시문을 무시해야 합니다.
정보 확장(Informational extensions)(캐시 동작의 변경이 필요하지 않은 확장)은 다른 지시문의 의미 체계를 변경하지 않고 추가할 수 있습니다.
동작 확장(Behavioral extensions)은 캐시 지시문의 기존 기반에 대한 수정자 역할을 하여 작동하도록 설계되었습니다. 새 지시문과 이전 지시문가 모두 제공되므로 새 지시문을 이해하지 못하는 응용 프로그램은 기본적으로 이전 지시문에 지정된 동작으로 설정되고 새 지시문을 이해하는 응용 프로그램은 이전 지시문과 관련된 요구 사항을 수정하는 것으로 인식할 것입니다. 이러한 방식으로 기존 cache-control 지시문에 대한 확장은 배포된 캐시를 중단하지 않고 만들 수 있습니다.
예를 들어, 개인 지시문에 대한 수정자 역할을 하는 "community"라는 가상의 새 응답 지시문을 고려하십시오. 개인 캐시 외에도 명명된 커뮤니티의 구성원만 공유하는 캐시는 응답을 캐시할 수 있습니다. UCI 커뮤니티가 공유 캐시에서 비공개 응답을 사용하도록 허용하려는 원본 서버는 다음을 포함하여 그렇게 할 수 있습니다.
Cache-Control: private, community="UCI"
이러한 커뮤니티 캐시 확장을 인식하는 캐시는 해당 확장에 따라 동작을 확장할 수 있습니다. 커뮤니티 캐시 확장을 인식하지 못하는 캐시는 이를 무시하고 개인 지시문을 준수합니다.
5.3. Expires
"Expires" 헤더 필드는 응답이 오래된 것으로 간주되는 날짜/시간을 제공합니다. 신선도 모델에 대한 자세한 내용은 섹션 4.2를 참조하십시오.
Expires 필드가 있다고 해서 원래 리소스가 해당 시간, 그 이전 또는 이후에 변경되거나 존재하지 않는다는 의미는 아닙니다.
Expires 값은 [RFC7231]의 섹션 7.1.1.1에 정의된 HTTP 날짜 타임스탬프입니다.
Expires = HTTP-date
예를 들어
Expires: Thu, 01 Dec 1994 16:00:00 GMT
캐시 수신자는 유효하지 않은 날짜 형식, 특히 값 "0"을 과거의 시간(즉, "이미 만료됨")을 나타내는 것으로 해석해야 합니다(MUST).
응답에 max-age 지시문(섹션 5.2.2.8)이 있는 Cache-Control 필드가 포함된 경우 수신자는 Expires 필드를 무시해야 합니다(MUST). 마찬가지로 응답에 s-maxage 지시문(섹션 5.2.2.9)이 포함된 경우 공유 캐시 수신자는 Expires 필드를 무시해야 합니다(MUST). 이 두 경우 모두 Expires의 값은 아직 Cache-Control 필드를 구현하지 않은 수신자를 위한 것입니다.
시계가 없는 원서버는 해당 값이 과거(항상 만료됨)의 고정 시간을 나타내거나 해당 값이 신뢰할 수 있는 시계가 있는 시스템 또는 사용자에 의해 리소스와 연결되지 않는 한 Expires 필드를 생성하면 안 됩니다(MUST NOT).
역사적으로 HTTP는 Expires 필드 값이 향후 1년을 넘지 않도록 요구했습니다. 더 긴 신선도 수명은 더 이상 금지되지 않지만 매우 큰 값은 문제를 일으키는 것으로 입증되었으며(예: 시간 값에 32비트 정수 사용으로 인한 클럭 오버플로) 많은 캐시가 그보다 훨씬 빨리 응답을 제거합니다.
5.4. Pragma
"Pragma" 헤더 필드는 HTTP/1.0 캐시와의 하위 호환성을 허용하여 클라이언트가 이해할 수 있는 "no-cache" 요청을 지정할 수 있습니다(Cache-Control은 HTTP/1.1까지 정의되지 않았음). Cache-Control 헤더 필드도 존재하고 요청에 이해되는 경우 Pragma는 무시됩니다.
HTTP/1.0에서 Pragma는 수신자에 대한 구현 지정 지시문을 위한 확장 가능한 필드로 정의되었습니다. 이 사양은 상호 운용성을 개선하기 위해 이러한 확장을 더 이상 사용하지 않습니다.
Pragma = 1#pragma-directive
pragma-directive = "no-cache" / extension-pragma
extension-pragma = token [ "=" ( token / quoted-string ) ]
Cache-Control 헤더 필드가 요청에 존재하지 않는 경우, 캐시는 "Cache-Control: no-cache"가 존재하는 것과 동일한 효과를 갖는 것으로 no-cache 요청 pragma-directive를 고려해야 합니다(섹션 5.2.1 참조).
no-cache 요청을 보낼 때 HTTP/1.1 캐시에서 다른 Cache-Control 응답 지시문을 대상으로 Cache-Control: no-cache를 의도적으로 생략하지 않는 한 클라이언트는 pragma 및 cache-control 지시문을 모두 포함해야 합니다. 예를 들어:
GET / HTTP/1.1
Host: www.example.com
Cache-Control: max-age=30
Pragma: no-cache
Cache-Control을 이해하지 못하는 구현이 캐시된 응답을 제공하는 것을 배제하면서 HTTP/1.1 캐시가 30초 이하의 응답을 제공하도록 제한합니다.
참고: 응답에서 "Pragma: no-cache"의 의미가 사양에 정의되어 있지 않기 때문에 응답에서 "Cache-Control: no-cache"를 안정적으로 대체할 수 없습니다.
5.5. Warning
"Warning" 헤더 필드는 상태 코드에 반영되지 않을 수 있는 메시지의 상태 또는 변환에 대한 추가 정보를 전달하는 데 사용됩니다. 이 정보는 일반적으로 메시지의 페이로드에 적용된 변환 또는 캐싱 작업으로 인해 발생할 수 있는 부정확성에 대해 경고하는 데 사용됩니다.
캐시 관련 및 기타 다른 목적으로 경고를 사용할 수 있습니다. 오류 상태 코드가 아닌 경고를 사용하여 이러한 응답을 실제 오류와 구분합니다.
경고 헤더 필드는 일반적으로 모든 메시지에 적용할 수 있지만 일부 경고 코드는 캐시에만 적용되며 응답 메시지에만 적용할 수 있습니다.
Warning = 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[ SP warn-date ]
warn-code = 3DIGIT
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
; the name or pseudonym of the server adding
; the Warning header field, for use in debugging
; a single "-" is recommended when agent unknown
warn-text = quoted-string
warn-date = DQUOTE HTTP-date DQUOTE경고 텍스트만 다른 동일한 경고 코드 번호가 있는 여러 경고를 포함하여 응답에서 여러 경고가 생성될 수 있습니다(원본 서버 또는 캐시에 의해).
하나 이상의 경고 헤더 필드를 수신하는 사용자 에이전트는 응답에 나타나는 순서대로 가능한 한 많은 헤더 필드를 사용자에게 알려야 합니다(SHOULD). 여러 경고 헤더 필드를 생성하는 발신자는 이 사용자 에이전트 동작을 염두에 두고 주문하는 것이 좋습니다. 새로운 경고 헤더 필드를 생성하는 발신자는 기존 경고 헤더 필드 뒤에 추가해야 합니다.
경고에는 3자리 경고 코드가 할당됩니다. 첫 번째 숫자는 검증 후 저장된 응답에서 경고를 삭제해야 하는지 여부를 나타냅니다.
- 1xx 경고 코드는 응답의 신선도 또는 유효성 검사 상태를 설명하므로 유효성 검사 후 캐시에서 삭제해야 합니다(MUST). 캐시된 항목의 유효성을 검사할 때 캐시에 의해서만 생성될 수 있으며 다른 상황에서는 생성되어서는 안 됩니다(MUST NOT).
- 2xx 경고 코드는 유효성 검사(예: 응답 내용의 손실 압축)에 의해 수정되지 않은 응답 내용의 일부 측면을 설명하며 전체 응답이 전송되지 않는 한 유효성 검사 후 캐시에 의해 삭제되어서는 안 됩니다(MUST NOT). 반드시 있어야 합니다(MUST).
보낸 사람이 HTTP/1.0만 구현하는 것으로 알려진 수신자에게 보낼 메시지에 하나 이상의 1xx 경고 코드를 생성하는 경우, 보낸 사람은 각 해당 경고 값에 메시지의 날짜 헤더 필드와 일치하는 경고 날짜를 포함해야 합니다(MUST). 예를 들어:
HTTP/1.1 200 OK
Date: Sat, 25 Aug 2012 23:34:45 GMT
Warning: 112 - "network down" "Sat, 25 Aug 2012 23:34:45 GMT"경고에는 오류(예: 로깅)를 설명하는 경고 텍스트가 함께 제공됩니다. 참고용일 뿐이며 그 내용은 warn-code의 해석에 영향을 미치지 않습니다.
경고 헤더 필드를 사용, 평가 또는 표시하는 수신자가 동일한 메시지의 날짜 값과 다른 경고 날짜를 받는 경우, 수신자는 메시지를 저장, 전달 또는 사용하기 전에 해당 warn-date를 포함하는 warning-value를 제외해야 합니다(MUST). 이를 통해 수신자는 캐시 유효성 검사 후 부적절하게 유지된 경고 값을 제외할 수 있습니다. 모든 warning-value가 제외되면 수신자는 Warning 헤더 필드도 제외해야 합니다(MUST).
다음 경고 코드는 이 사양에 의해 정의되며 각각 권장되는 영어 경고 텍스트와 그 의미에 대한 설명이 있습니다. 추가 경고 코드를 정의하는 절차는 섹션 7.2.1에 설명되어 있습니다.
5.5.1. Warning: 110 - "Response is Stale"
캐시는 보낸 응답이 오래되었을 때마다 이것을 생성해야 합니다(SHOULD).
5.5.2. Warning: 111 - "Revalidation Failed"
캐시는 서버에 도달할 수 없기 때문에 응답 유효성 검사 시도가 실패했기 때문에 부실 응답을 보낼 때 이를 생성해야 합니다(SHOULD).
5.5.3. Warning: 112 - "Disconnected Operation"
캐시는 일정 기간 동안 네트워크의 나머지 부분과 의도적으로 연결이 끊어진 경우 이를 생성해야 합니다(SHOULD).
5.5.4. Warning: 113 - "Heuristic Expiration"
캐시는 경험적으로 24시간보다 긴 신선도 수명을 선택하고 응답의 수명이 24시간보다 큰 경우 이를 생성해야 합니다(SHOULD).
5.5.5. Warning: 199 - "Miscellaneous Warning"
경고 텍스트에는 인간 사용자에게 표시되거나 기록되는 임의의 정보가 포함될 수 있습니다. 이 경고를 받는 시스템은 사용자에게 경고를 표시하는 것 외에 자동화된 조치를 취해서는 안 됩니다(MUST NOT).
5.5.6. Warning: 214 - "Transformation Applied"
이 경고 코드는 이 경고 코드가 응답에 이미 나타나지 않는 한 content-coding, media-type 변경 또는 representation data 수정과 같은 응답 내용에 대한 변환을 적용하는 경우 프록시에 의해 추가되어야 합니다(MUST).
5.5.7. Warning: 299 - "Miscellaneous Persistent Warning"
경고 텍스트에는 인간 사용자에게 표시되거나 기록되는 임의의 정보가 포함될 수 있습니다. 이 경고를 받은 시스템은 자동화된 조치를 취해서는 안 됩니다(MUST NOT).
6. History Lists
사용자 에이전트는 종종 세션에서 이전에 검색된 응답 내용을 다시 표시하는 데 사용할 수 있는 "뒤로" 버튼 및 기록 목록과 같은 기록 메커니즘을 가지고 있습니다.
신선도 모델(섹션 4.2)이 기록 메커니즘에 반드시 적용되는 것은 아닙니다. 즉, 기록 메커니즘은 만료된 경우에도 이전 응답 내용을 표시할 수 있습니다.
이는 기록 메커니즘이 사용자에게 보기가 오래되었을 수 있음을 알리거나 캐시 지시문(예: Cache-Control: no-store)을 준수하는 것을 금지하지 않습니다.
7. IANA Considerations
7.1. Cache Directive Registry
"HTTP(Hypertext Transfer Protocol) 캐시 지시문 레지스트리"는 캐시 지시문의 네임스페이스를 정의합니다. 아래 URL에서 생성되어 현재 유지 관리되고 있습니다.
<http://www.iana.org/assignments/http-cache-directives>.
7.1.1. Procedure
등록에는 다음 필드가 포함되어야 합니다(MUST).
- 캐시 지시어 이름
- 사양 텍스트에 대한 포인터
이 네임스페이스에 추가할 값은 IETF 검토가 필요합니다([RFC5226], 섹션 4.1 참조).
7.1.2. Considerations for New Cache Control Directives
새로운 확장 지시문은 다음을 정의하는 것을 고려해야 합니다.
- 지시문이 여러 번 지정된다는 것은 무엇을 의미하는지,
- 지시어가 인수를 취하지 않을 때, 인수가 있을 때의 의미,
- 지시문에 인수가 필요한 경우 누락된 경우의 의미,
- 지시문이 요청, 응답에 특정한지 또는 둘 중 하나에서 사용할 수 있는지 여부.
섹션 5.2.3도 참조하십시오.
7.1.3. Registrations
레지스트리는 아래 등록으로 채워졌습니다.
+------------------------+----------------------------------+
| Cache Directive | Reference |
+------------------------+----------------------------------+
| max-age | Section 5.2.1.1, Section 5.2.2.8 |
| max-stale | Section 5.2.1.2 |
| min-fresh | Section 5.2.1.3 |
| must-revalidate | Section 5.2.2.1 |
| no-cache | Section 5.2.1.4, Section 5.2.2.2 |
| no-store | Section 5.2.1.5, Section 5.2.2.3 |
| no-transform | Section 5.2.1.6, Section 5.2.2.4 |
| only-if-cached | Section 5.2.1.7 |
| private | Section 5.2.2.6 |
| proxy-revalidate | Section 5.2.2.7 |
| public | Section 5.2.2.5 |
| s-maxage | Section 5.2.2.9 |
| stale-if-error | [RFC5861], Section 4 |
| stale-while-revalidate | [RFC5861], Section 3 |
+------------------------+----------------------------------+
7.2. Warn Code Registry
"HTTP(Hypertext Transfer Protocol) 경고 코드" 레지스트리는 경고 코드의 네임스페이스를 정의합니다. 생성되어 현재 <http://www.iana.org/assignments/http-warn-codes>에서 관리되고 있습니다.
7.2.1. Procedure
등록에는 다음 필드가 포함되어야 합니다.
- 경고 코드(3자리)
- 간단한 설명
- 사양 텍스트에 대한 포인터
이 네임스페이스에 추가할 값은 IETF 검토가 필요합니다([RFC5226], 섹션 4.1 참조).
7.2.2. Registrations
레지스트리는 아래 등록들로 채워졌습니다.
+-----------+----------------------------------+---------------+
| Warn Code | Short Description | Reference |
+-----------+----------------------------------+---------------+
| 110 | Response is Stale | Section 5.5.1 |
| 111 | Revalidation Failed | Section 5.5.2 |
| 112 | Disconnected Operation | Section 5.5.3 |
| 113 | Heuristic Expiration | Section 5.5.4 |
| 199 | Miscellaneous Warning | Section 5.5.5 |
| 214 | Transformation Applied | Section 5.5.6 |
| 299 | Miscellaneous Persistent Warning | Section 5.5.7 |
+-----------+----------------------------------+---------------+
7.3. Header Field Registration
HTTP 헤더 필드는 <http://www.iana.org/assignments/message-headers/>에서 관리되는 "Message Headers" 레지스트리 내에 등록됩니다.
이 문서는 다음 HTTP 헤더 필드를 정의하므로 "Permanent Message Header Field Names" 레지스트리가 그에 따라 업데이트되었습니다([BCP90] 참조).
+-------------------+----------+----------+-------------+
| Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------+
| Age | http | standard | Section 5.1 |
| Cache-Control | http | standard | Section 5.2 |
| Expires | http | standard | Section 5.3 |
| Pragma | http | standard | Section 5.4 |
| Warning | http | standard | Section 5.5 |
+-------------------+----------+----------+-------------+
변경에 대한 총괄은 "IETF(iesg@ietf.org) - Internet Engineering Task Force"입니다.
8. Security Considerations
이 섹션은 HTTP 캐싱과 관련된 알려진 보안 문제를 개발자, 정보 제공자 및 사용자에게 알리기 위한 것입니다. 보다 일반적인 보안 고려 사항은 HTTP 메시징 [RFC7230] 및 의미론 [RFC7231]에서 다룹니다.
캐시의 내용은 악의적인 악용 대상이 되기 때문에 캐시는 추가적인 잠재적 취약성을 노출합니다. 캐시 내용은 HTTP 요청이 완료된 후에도 지속되기 때문에 캐시에 대한 공격은 사용자가 정보가 네트워크에서 제거되었다고 믿은 후에도 오랫동안 정보를 노출할 수 있습니다. 따라서 캐시 내용은 민감한 정보로 보호되어야 합니다.
특히, 공유 캐시에 저장되어 다양한 공격이 증폭될 수 있습니다. 이러한 "cache poisoning" 공격은 캐시를 사용하여 악의적인 페이로드를 많은 클라이언트에 배포하며 공격자가 구현 결함, 상승된 권한 또는 기타 기술을 사용하여 이러한 응답을 캐시에 삽입할 수 있는 경우 특히 효과적입니다. cache poisoning에 대한 일반적인 공격 벡터 중 하나는 프록시와 사용자 에이전트에서 메시지 구문 분석의 차이를 악용하는 것입니다. 관련 요구 사항은 [RFC7230]의 섹션 3.3.3을 참조하십시오.
마찬가지로 구현 결함(및 캐시 작업에 대한 오해)으로 인해 개인 정보로 간주되는 민감한 정보(예: 인증 자격 증명)가 캐싱되어 권한이 없는 당사자에게 노출될 수 있습니다.
또한 캐시를 사용하면 개인 정보 보호 문제가 발생할 수 있습니다. 예를 들어, 두 명의 사용자가 캐시를 공유하고 첫 번째 사용자가 사이트를 탐색하는 경우 두 번째 사용자는 캐시 덕분에 해당 사이트의 리소스가 더 빨리 로드되기 때문에 다른 사용자가 해당 사이트를 방문했음을 감지할 수 있습니다.
Set-Cookie 응답 헤더 필드 [RFC6265]는 캐싱을 금지하지 않습니다. Set-Cookie 헤더 필드가 있는 캐시 가능한 응답은 캐시에 대한 후속 요청을 충족하는 데 사용될 수 있으며 종종 사용됩니다. 이러한 응답의 캐싱을 제어하려는 서버는 적절한 Cache-Control 응답 헤더 필드를 내보내는 것이 좋습니다.
9. Acknowledgments
[RFC7230]의 섹션 10을 참조하십시오.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
10.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale Content", RFC 5861, April 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
Appendix A. Changes from RFC 2616
사양은 명확성을 위해 실질적으로 재작성되었습니다.
인증된 응답을 캐시할 수 있는 조건이 명확해졌습니다. (섹션 3.2)
새로운 상태 코드는 이제 캐시가 휴리스틱 신선도를 사용할 수 있도록 정의할 수 있습니다. 캐시는 이제 쿼리 구성 요소가 있는 URI에 대한 경험적 신선도를 계산할 수 있습니다. (섹션 4.2.2)
Age 계산 알고리즘은 이제 덜 보수적입니다. 캐시는 이제 정확하게 추측할 수 없기 때문에 시간대가 있는 날짜를 유효하지 않은 것처럼 처리해야 합니다. (섹션 4.2.3)
Content-Location 응답 헤더 필드는 유효성 검사 시 사용할 적절한 응답을 결정하는 데 더 이상 사용되지 않습니다. (섹션 4.3)
사용할 캐시된 협상된 응답을 선택하는 알고리즘이 여러 가지 방법으로 명확해졌습니다. 특히 이제 헤더 필드 선택을 처리할 때 헤더별 정규화를 명시적으로 허용합니다. (섹션 4.1)
무효화를 수행할 때 서비스 거부 공격 회피에 대한 요구 사항이 명확해졌습니다. (섹션 4.4)
캐시 무효화는 성공적인 응답을 받은 경우에만 발생합니다. (섹션 4.4)
캐시 지시문은 대소문자를 구분하지 않도록 명시적으로 정의됩니다. 오직 하나만 예상되는 캐시 지시문의 여러 인스턴스 처리가 이제 정의되었습니다. (섹션 5.2)
"no-store" 요청 지시문은 응답에 적용되지 않습니다. 즉, 캐시는 저장소가 없는 요청을 충족할 수 있으며 무효화하지 않습니다. (섹션 5.2.1.5)
private 및 no-cache 캐시 지시문의 한정된 형식은 널리 구현되지 않는 것으로 알려져 있습니다. 예를 들어 "private=foo"는 많은 캐시에서 단순히 "private"로 해석됩니다. 또한 no-cache의 정규화된 형식의 의미가 명확해졌습니다. (섹션 5.2.2)
"no-cache" 응답 지시어의 의미가 명확해졌습니다. (섹션 5.2.2.2)
Expires 헤더 필드 값에 대한 1년 제한이 제거되었습니다. 대신 합리적인 값을 사용하는 이유가 제공됩니다. (섹션 5.3)
Pragma 헤더 필드는 이제 이전 버전과의 호환성을 위해서만 정의됩니다. 향후 pragma는 더 이상 사용되지 않습니다. (섹션 5.4)
널리 구현되지 않았기 때문에 경고 헤더 필드의 생성 및 처리에 관한 일부 요구 사항이 완화되었습니다. 또한 경고 헤더 필드는 더 이상 RFC 2047 인코딩을 사용하지 않으며 이러한 측면이 구현되지 않았기 때문에 여러 언어를 허용하지 않습니다. (섹션 5.5)
이 사양은 캐시 지시문 및 경고 코드 레지스트리를 소개하고 새 캐시 지시문에 대한 고려 사항을 정의합니다. (섹션 7.1 및 섹션 7.2)
Appendix B. Imported ABNF
다음 핵심 규칙은 [RFC5234]의 부록 B.1에 정의된 대로 참조로 포함됩니다. ALPHA(문자), CR(캐리지 리턴), CRLF(CR LF), CTL(제어), DIGIT(십진수 0-9) , DQUOTE(큰따옴표), HEXDIG(16진수 0-9/A-F/a-f), LF(줄 바꿈), OCTET(모든 8비트 데이터 시퀀스), SP(공백) 및 VCHAR(보이는 모든 US-ASCII 문자 ).
아래 규칙은 [RFC7230]에 정의되어 있습니다.
OWS = <OWS, see [RFC7230], Section 3.2.3>
field-name = <field-name, see [RFC7230], Section 3.2>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
port = <port, see [RFC7230], Section 2.7>
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
uri-host = <uri-host, see [RFC7230], Section 2.7>
아래 규칙은 다른 부분에서 정의됩니다.
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
Appendix C. Collected ABNF
아래 수집된 ABNF에서 목록 규칙은 [RFC7230]의 섹션 1.2에 따라 확장됩니다.
Age = delta-seconds
Cache-Control = *( "," OWS ) cache-directive *( OWS "," [ OWS
cache-directive ] )
Expires = HTTP-date
HTTP-date = <HTTP-date, see [RFC7231], Section 7.1.1.1>
OWS = <OWS, see [RFC7230], Section 3.2.3>
Pragma = *( "," OWS ) pragma-directive *( OWS "," [ OWS
pragma-directive ] )
Warning = *( "," OWS ) warning-value *( OWS "," [ OWS warning-value ]
)
cache-directive = token [ "=" ( token / quoted-string ) ]
delta-seconds = 1*DIGIT
extension-pragma = token [ "=" ( token / quoted-string ) ]
field-name = <field-name, see [RFC7230], Section 3.2>
port = <port, see [RFC7230], Section 2.7>
pragma-directive = "no-cache" / extension-pragma
pseudonym = <pseudonym, see [RFC7230], Section 5.7.1>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6>
uri-host = <uri-host, see [RFC7230], Section 2.7>
warn-agent = ( uri-host [ ":" port ] ) / pseudonym
warn-code = 3DIGIT
warn-date = DQUOTE HTTP-date DQUOTE
warn-text = quoted-string
warning-value = warn-code SP warn-agent SP warn-text [ SP warn-date
]
https://www.rfc-editor.org/rfc/rfc7234
RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
www.rfc-editor.org
댓글