HTTP 캐싱

이 문서에서 키워드 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 BCP 14의 정의에 따라, 오직 모두 대문자로 나타날 때에만 여기에 설명된 대로 해석되어야 합니다. 자세한 내용은 [RFC2119] 및 [RFC8174]를 참조하십시오.

섹션 2 of [HTTP]는 적합성 기준을 정의하고 오류 처리에 관한 고려사항을 포함합니다.

이 명세서는 [RFC5234]의 확장된 백커스-나우어 형식(ABNF) 표기법을 사용하며, [RFC7405]에서 정의된 문자열의 대소문자 구분 표기법 확장을 포함합니다.

또한 이 명세서는 섹션 5.6.1 of [HTTP]에 정의된 리스트 확장을 사용하여 "#" 연산자를 이용한 쉼표로 구분된 목록의 간결한 정의를 허용합니다(이는 "*" 연산자가 반복을 나타내는 방식과 유사합니다). 부록 A에는 모든 리스트 연산자가 표준 ABNF 표기법으로 확장된 수집된 문법이 표시됩니다.

• Connection 헤더 필드와 그 안에 나열된 필드 이름은 섹션 7.6.1 of [HTTP]에 의해 메시지를 전달하기 전에 제거되어야 합니다. 이는 저장 전에 제거함으로써 구현될 MAY 있습니다.
• 마찬가지로 일부 필드의 의미론은 메시지를 전달하기 전에 해당 필드들을 제거하도록 요구하며, 이는 저장 전에 제거함으로써 구현될 수 있습니다(이 역시 MAY). 몇 가지 예는 섹션 7.6.1 of [HTTP]를 참조하십시오.
• no-cache(섹션 5.2.2.4) 및 private(섹션 5.2.2.7) 캐시 지시어는 각각 모든 캐시 또는 공유 캐시가 헤더 필드를 저장하는 것을 방지하는 인수를 가질 수 있습니다.
• 캐시가 요청을 전달할 때 사용하는 프록시에 특화된 헤더 필드는, 캐시가 프록시의 정체성을 캐시 키에 포함하지 않는 한 저장해서는 안 됩니다(MUST NOT). 사실상 이는 Proxy-Authenticate(섹션 11.7.1 of [HTTP]), Proxy-Authentication-Info(섹션 11.7.3 of [HTTP]), 및 Proxy-Authorization(섹션 11.7.2 of [HTTP])에 국한됩니다.

캐시는 트레일러 필드를 헤더 필드와 별도로 저장하거나 버릴 수 있습니다(MAY). 그러나 캐시는 트레일러 필드를 헤더 필드와 결합해서는 안 됩니다(MUST NOT).

캐시는 여러 상황에서(예: 섹션 3.4, 섹션 4.3.4, 및 섹션 4.3.5 참조) 다른(일반적으로 더 최신의) 응답으로부터 저장된 응답의 헤더 필드를 업데이트해야 합니다.

• 섹션 3.1(헤더 및 트레일러 필드 저장)에서 저장에서 제외된 헤더 필드,
• 캐시의 저장된 응답이 의존하는 헤더 필드(아래 설명 참조),
• 수신자가 자동으로 처리하고 제거하는 헤더 필드(아래 설명 참조), 및
• Content-Length 헤더 필드.

일부 경우(특히 사용자 에이전트의 캐시)에는 수신된 응답을 처리한 결과를 저장하고 응답 자체를 저장하지 않으며, 이러한 저장된 처리 결과에 영향을 미치는 헤더 필드를 업데이트하면 일관성 문제와 보안 문제가 발생할 수 있습니다. 이러한 상황의 캐시는 예외적으로 이러한 헤더 필드를 저장된 응답의 업데이트에서 생략할 수(MAY) 있지만, 그러한 생략은 저장된 응답의 무결성을 보장하는 데 필요한 필드로 제한해야 합니다(SHOULD).

예를 들어, 브라우저는 응답을 수신하는 동안 콘텐츠 인코딩을 디코드하여 저장된 데이터와 응답의 원래 메타데이터 사이에 불일치가 생길 수 있습니다. 이러한 경우 저장된 메타데이터를 서로 다른 Content-Encoding 헤더 필드로 업데이트하는 것은 문제를 일으킬 수 있습니다. 마찬가지로 브라우저가 응답에서 받은 콘텐츠 대신 파싱된 HTML 트리를 저장하는 경우, Content-Type 헤더 필드를 업데이트하는 것은 파싱 시 형식에 대한 가정이 더 이상 유효하지 않게 되어 작동하지 않을 것입니다.

더욱이 일부 필드는 Content-Range 헤더 필드와 같이 HTTP 구현에 의해 자동으로 처리되고 제거됩니다. 구현체는 그러한 헤더 필드를 실제로 처리하지 않더라도 업데이트에서 자동으로 생략할 수(MAY) 있습니다.

Content-* 접두어가 헤더 필드가 업데이트에서 생략된다는 신호는 아님을 유의하십시오; 이는 MIME 헤더 필드에 대한 관례일 뿐이며 HTTP 고유의 것은 아닙니다.

요청 메서드가 GET이고 응답 상태 코드가 200 (OK)이며 전체 응답 헤더 섹션을 수신한 경우, 캐시는 응답이 완전하지 않은 상태라도 저장할 수 있습니다(MAY)(자세한 내용은 섹션 6.1 of [HTTP]). 저장된 응답은 불완전한 것으로 기록되어야 합니다. 마찬가지로 206 (Partial Content) 응답은 불완전한 200 (OK) 응답인 것처럼 저장될 수 있습니다. 그러나 캐시는 Range 및 Content-Range 헤더 필드를 지원하지 않거나 해당 필드에서 사용된 범위 단위를 이해하지 못하는 경우 불완전하거나 부분 콘텐츠 응답을 저장해서는 안 됩니다(MUST NOT).

캐시는 이후 범위 요청(섹션 14.2 of [HTTP])을 만들어 저장된 불완전 응답을 완성하고 성공한 응답을 저장된 응답과 결합하여 완성할 수 있습니다(MAY), 이는 섹션 3.4에 정의되어 있습니다. 캐시는 응답을 완성하지 않았거나 요청이 불완전하고 지정된 범위가 저장된 불완전 응답 내에 완전히 포함되지 않는 한 불완전한 응답을 사용하여 요청에 응답해서는 안 됩니다(MUST NOT). 또한 캐시는 클라이언트에 부분 응답을 보낼 때 반드시 206 (Partial Content) 상태 코드를 사용하여 명시적으로 표시해야 합니다(MUST NOT send a partial response to a client without explicitly marking it using the 206 status code).

연결이 조기에 종료되었거나 요청이 하나 이상의 Range 지정자를 사용한 경우(섹션 14.2 of [HTTP]), 응답이 부분 표현만 전송할 수 있습니다. 여러 번의 이러한 전송 후에 캐시는 동일한 표현의 여러 범위를 수신했을 수 있습니다. 캐시는 이러한 범위를 단일 저장된 응답으로 결합하고 이후 요청을 만족시키기 위해 해당 응답을 재사용할 수 있습니다(MAY), 단 그 모두가 동일한 강한 검증자(strong validator)를 공유하고 캐시가 섹션 15.3.7.3 of [HTTP]에 명시된 클라이언트 요구사항을 준수하는 경우에 한합니다.

새 응답을 하나 이상의 저장된 응답과 결합할 때, 캐시는 섹션 3.2에 따라 새 응답에 제공된 헤더 필드를 사용하여 저장된 응답의 헤더 필드를 반드시 업데이트해야 합니다(MUST).

공유 캐시는 요청에 Authorization 헤더 필드가 포함된 요청에 대한 캐시된 응답을 이후의 어떤 요청을 만족시키는 데 사용할 수 없습니다(MUST NOT), 단 응답에 공유 캐시에 의해 저장되는 것을 명시적으로 허용하는 응답 지시어를 가진 Cache-Control 필드가 포함되어 있고, 캐시가 해당 응답에 대해 그 지시어의 요구사항을 준수하는 경우는 예외입니다.

이 명세서에서 다음 응답 지시어들은 이러한 효과를 가집니다: must-revalidate(섹션 5.2.2.2), public(섹션 5.2.2.9), 및 s-maxage(섹션 5.2.2.10).

캐시가 저장된 응답으로 만족시킬 수 있는 요청을 수신했고 그 저장된 응답에 Vary 헤더 필드(섹션 12.5.5 of [HTTP])가 포함된 경우, 캐시는 그 Vary 필드가 지명한 모든 제시된 요청 헤더 필드가 원래 요청(즉, 캐시된 응답을 저장하게 한 요청)의 필드와 일치하지 않으면 재검증 없이 저장된 응답을 사용해서는 안 됩니다(MUST NOT).

• 헤더 필드 문법상 허용되는 경우 공백을 추가하거나 제거하는 것
• 같은 필드 이름을 가진 여러 헤더 필드 라인을 결합하는 것(자세한 내용은 섹션 5.2 of [HTTP] 참조)
• 헤더 필드의 규격에 따라 의미가 동일한 방식으로 두 헤더 필드 값을 정규화하는 것(예: 순서가 중요하지 않은 경우 값의 재정렬; 값이 대소문자 구분이 아닌 경우의 대소문자 정규화)

(정규화 후) 요청에서 헤더 필드가 없으면, 그 필드는 다른 요청에서도 동일하게 없을 때에만 일치할 수 있습니다.

Vary 헤더 필드 값에 "*"가 포함된 저장된 응답은 항상 일치하지 못합니다.

여러 저장된 응답이 일치하는 경우, 캐시는 하나를 선택해야 합니다. 지명된 요청 헤더 필드에 우선순위를 결정하는 알려진 메커니즘(예: Accept 등의 q값)이 있는 경우, 그 메커니즘을 사용하여 선호되는 응답을 선택할 수 있습니다(MAY). 그러한 메커니즘이 없거나 동등한 우선순위를 주는 응답들이 있는 경우에는 가장 최근의 응답(Date 헤더 필드로 결정)이 선택됩니다(자세한 내용은 섹션 4 참조).

일부 자원은 기본 응답(즉 요청이 선호도를 표현하지 않을 때 전송되는 것)에서 Vary 헤더 필드를 누락하여, 이후 그 자원에 대한 요청에 대해 더 선호되는 응답이 있어도 기본 응답을 선택하게 만드는 실수를 범합니다. 캐시에 대상 URI에 대해 여러 저장된 응답이 있고 그 중 하나 이상이 Vary 헤더 필드를 누락한 경우, 캐시는 유효한 Vary 필드 값을 가진 저장된 응답 중 가장 최근의 것을 선택하는 것이 바람직합니다(SHOULD; 섹션 4.2.3 참조).

저장된 응답과 일치하는 것이 없으면, 캐시는 제시된 요청을 만족시킬 수 없습니다. 일반적으로 요청은 원점 서버로 전달되며, 캐시가 이미 저장한 응답을 설명하기 위해 전제조건이 추가될 수 있습니다(섹션 4.3).

신선한(fresh) 응답은 그 연령이 아직 신선도 수명을 초과하지 않은 응답입니다. 반대로 만료된(stale) 응답은 그 연령이 신선도 수명을 초과한 경우입니다.

응답의 신선도 수명(freshness lifetime)은 원점 서버에서 생성된 시점과 만료 시점 사이의 기간입니다. 명시적 만료 시간(explicit expiration time)은 원점 서버가 저장된 응답을 더 이상의 검증 없이 캐시가 사용하지 못하도록 의도한 시간인 반면, 휴리스틱 만료 시간(heuristic expiration time)은 명시적 만료 시간이 제공되지 않을 때 캐시가 할당하는 시간입니다.

응답의 연령(age)은 응답이 원점 서버에서 생성되었거나 성공적으로 검증된 이후 경과한 시간입니다.

응답이 신선하면 원점 서버에 접촉하지 않고 후속 요청을 만족시키는 데 사용할 수 있어 효율성이 향상됩니다.

신선도를 결정하는 주요 메커니즘은 원점 서버가 Expires 헤더 필드(섹션 5.3) 또는 max-age 응답 지시어(섹션 5.2.2.1)를 사용하여 미래의 명시적 만료 시간을 제공하는 것입니다. 일반적으로 원점 서버는 만료 시간에 도달하기 전에 표현이 의미적으로 크게 변경될 가능성이 낮다고 판단하여 응답에 미래의 명시적 만료 시간을 할당합니다.

원점 서버가 캐시로 하여금 모든 요청을 검증하도록 강제하려는 경우, 명시적 만료 시간을 과거로 설정하여 응답이 이미 만료되었음을 나타낼 수 있습니다. 규격을 준수하는 캐시는 일반적으로 만료된 캐시 응답을 재사용하기 전에 검증합니다(자세한 내용은 섹션 4.2.4 참조).

원점 서버가 항상 명시적 만료 시간을 제공하지 않기 때문에, 캐시는 특정 상황에서 만료 시간을 결정하기 위해 휴리스틱을 사용할 수 있습니다(자세한 내용은 섹션 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).
• 캐시 수신자는 지역 시간대를 연령이나 만료 시간의 계산 또는 비교에 영향을 미치게 해서는 안 됩니다(MUST NOT).
• 캐시 수신자는 "GMT"가 아닌 구역 약어(zone abbreviation)를 가진 날짜를 만료 계산에 사용할 수 없다고 간주하는 것이 바람직합니다(SHOULD).

신선도는 캐시 동작에만 적용되며, 사용자 에이전트가 표시를 새로고침하거나 리소스를 다시 로드하도록 강제하는 데 사용할 수 없다는 점에 유의하십시오. 캐시와 기록(history) 메커니즘의 차이에 대해서는 섹션 6을 참조하십시오.

캐시가 요청된 URI에 대해 하나 이상의 저장된 응답을 가지고 있으나 그 어떤 것도 제공할 수 없는 경우(예: 신선하지 않거나 선택할 수 없음; 섹션 4.1 참조), 캐시는 전달되는 요청에서 조건부 요청 메커니즘(섹션 13 of [HTTP])을 사용하여 다음 수신 서버가 저장된 응답 중 유효한 것을 선택하여 사용하거나, 저장된 응답의 메타데이터를 갱신하거나, 저장된 응답을 새 응답으로 교체할 기회를 제공할 수 있습니다. 이 과정을 저장된 응답의 검증(validating) 또는 재검증(revalidating)이라고 합니다.

PUT, POST, DELETE와 같은 안전하지 않은 요청 메서드(섹션 9.2.1 of [HTTP])는 원점 서버에서 상태를 변경할 가능성이 있으므로, 중간에 개입하는 캐시는 저장된 응답을 최신 상태로 유지하기 위해 무효화해야 합니다(MUST).

캐시는 안전하지 않은 요청 메서드에 대해 비오류 상태 코드를 수신할 때 대상 URI(섹션 7.1 of [HTTP])를 무효화해야 합니다(MUST).

캐시는 안전하지 않은 요청 메서드에 대해 비오류 상태 코드를 수신할 때 다른 URI들을 무효화할 수 있습니다(MAY). 특히, 응답 헤더 필드의 Location 및 Content-Location에 있는 URI(존재하는 경우)는 무효화 대상이 될 수 있습니다. 다른 URI는 이 문서에 명시되지 않은 메커니즘을 통해 발견될 수 있습니다. 그러나 무효화 대상의 원점(섹션 4.3.1 of [HTTP])이 대상 URI의 원점과 다르면, 캐시는 이러한 조건에서 무효화를 트리거해서는 안 됩니다(MUST NOT). 이는 서비스 거부 공격을 방지하는 데 도움이 됩니다.

무효화(Invalidate)는 캐시가 주어진 URI와 대상 URI가 일치하는 모든 저장된 응답을 제거하거나, 이후 요청에 대해 전송되기 전에 반드시 검증해야 하는 "무효화" 상태로 표시함을 의미합니다.

"비오류 응답(non-error response)"은 2xx (Successful) 또는 3xx (Redirection) 상태 코드를 가진 응답입니다.

이것이 모든 적절한 응답이 전역적으로 무효화된다는 것을 보장하지는 않는다는 점에 유의하십시오; 상태 변경 요청은 그것이 통과하는 캐시들에서만 응답을 무효화합니다.

"Age" 응답 헤더 필드는 응답이 원본 서버에서 생성되었거나 성공적으로 검증된 이후 경과한 시간에 대한 송신자의 추정치를 전달합니다. Age 값의 계산 방법은 섹션 4.2.3에 규정된 대로입니다.

  Age = delta-seconds

Age 필드 값은 초 단위의 시간을 나타내는 음이 아닌 정수입니다(참조: 섹션 1.2.2).

비록 이 필드가 단일 헤더 필드로 정의되어 있지만, 리스트 기반의 Age 필드 값을 접한 캐시는 첫 번째 멤버를 사용하고 이후 멤버는 버리는 것이 권장됩니다(SHOULD).

위에서 언급한 대로 추가 멤버를 삭제한 후의 필드 값이 유효하지 않은 경우(예: 음이 아닌 정수가 아닌 값이 포함된 경우), 캐시는 해당 필드를 무시하는 것이 권장됩니다(SHOULD).

Age 헤더 필드의 존재는 해당 응답이 이 요청에 대해 원점 서버에서 생성되거나 검증된 것이 아님을 암시합니다. 그러나 Age 헤더 필드가 없다고 해서 원점 서버에 연락한 적이 없음을 의미하지는 않습니다.

"Cache-Control" 헤더 필드는 요청/응답 체인에 있는 캐시들을 위한 지시어들을 나열하는 데 사용됩니다. 캐시 지시어는 단방향이며, 요청에 지시어가 존재한다고 해서 동일한 지시어가 응답에 존재하거나 복사된다는 것을 의미하지 않습니다.

섹션 5.2.3에서는 다른 곳에서 정의된 Cache-Control 지시어들이 어떻게 처리되는지에 대한 정보를 제공합니다.

프록시(캐시를 구현하든 하지 않든 관계없이)는 전달되는 메시지에서 캐시 지시어를 그 유효성에 관계없이 전달해야 합니다(MUST), 이는 지시어가 요청/응답 체인상의 모든 수신자에 적용될 수 있기 때문입니다. 특정 캐시에 지시어를 목표로 삼는 것은 불가능합니다.

캐시 지시어는 토큰으로 식별되며 대소문자 구분 없이 비교됩니다. 선택적 인수를 가질 수 있으며 인수는 토큰 또는 인용 문자열(quoted-string) 문법을 사용할 수 있습니다. 아래 정의된 인수를 가지는 지시어의 경우, 수신자는 생성 시 특정 형식이 요구되더라도 두 형식 모두를 수용하는 것이 바람직합니다.

  Cache-Control   = #cache-directive

  cache-directive = token [ "=" ( token / quoted-string ) ]

아래에 정의된 캐시 지시어들에 대해서는, 별도로 명시하지 않는 한 인수가 정의되거나 허용되지 않습니다.

"Expires" 응답 헤더 필드는 응답이 만료된 것으로 간주되는 이후의 날짜/시간을 제공합니다. 신선도 모델에 대한 추가 논의는 섹션 4.2를 참조하십시오.

Expires 헤더 필드의 존재는 원래 자원이 해당 시점에 변경되거나 존재하지 않게 될 것임을 암시하지 않습니다.

Expires 필드 값은 HTTP-date 타임스탬프입니다(정의: 섹션 5.6.7). 캐시에 특화된 구문 분석 요구사항은 또한 섹션 4.2를 참조하십시오.

  Expires = HTTP-date

예:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

캐시 수신자는 특히 값 "0"을 포함한 잘못된 날짜 형식을 과거의 시간(즉, 이미 만료된 것으로)으로 해석해야 합니다(MUST).

응답에 Cache-Control 헤더 필드가 있고 그 안에 max-age 지시어(섹션 5.2.2.1)가 포함되어 있으면, 수신자는 Expires 헤더 필드를 무시해야 합니다(MUST). 마찬가지로 응답에 s-maxage 지시어(섹션 5.2.2.10)가 포함되어 있으면, 공유 캐시 수신자는 Expires 헤더 필드를 무시해야 합니다(MUST). 이 두 경우 모두 Expires의 값은 Cache-Control 헤더 필드를 아직 구현하지 않은 수신자를 위한 것입니다.

시계가 없는 원점 서버는(정의: 섹션 5.6.7) Expires 헤더 필드를 생성해서는 안 됩니다(MUST NOT), 단 그 값이 과거의 고정 시간(항상 만료됨)을 나타내거나 그 값이 시계를 가진 시스템에 의해 자원과 연관되었을 때는 예외입니다.

역사적으로 HTTP는 Expires 필드 값이 미래로 최대 1년을 초과하지 않도록 요구했습니다. 더 긴 신선도 수명이 더 이상 금지되지는 않지만, 매우 큰 값은 문제(예: 시간 값에 대해 32비트 정수를 사용하는 경우 시계 오버플로)를 일으키는 것으로 입증되었고, 많은 캐시는 훨씬 더 빨리 응답을 축출할 것입니다.

"Pragma" 요청 헤더 필드는 HTTP/1.0 캐시를 위해 정의되었으며, 당시에는 Cache-Control이 HTTP/1.1까지 정의되지 않았으므로 클라이언트가 "no-cache" 요청을 지정할 수 있게 했습니다.

그러나 현재는 Cache-Control의 지원이 널리 퍼져 있습니다. 결과적으로 이 명세서는 Pragma를 사용 중단(deprecate)합니다.

"Warning" 헤더 필드는 상태 코드에 반영되지 않을 수 있는 메시지의 상태 또는 변형에 대한 추가 정보를 전달하는 데 사용되었습니다. 이 명세서는 Warning을 널리 생성되거나 사용자에게 노출되지 않으므로 폐지합니다. Warning이 전달하던 정보는 Age와 같은 다른 헤더 필드를 검사함으로써 얻을 수 있습니다.

캐시에 악의적인 콘텐츠를 저장하면 공격자가 여러 사용자에게 영향을 미치도록 범위를 확장할 수 있습니다. 이러한 "캐시 중독" 공격은 공격자가 구현 결함, 권한 상승 또는 다른 기법을 사용하여 응답을 캐시에 삽입할 때 발생합니다. 공유 캐시가 많은 클라이언트에게 악의적 콘텐츠를 배포하는 데 사용될 때 특히 효과적입니다.

캐시 중독의 일반적인 공격 벡터 중 하나는 프록시와 사용자 에이전트에서의 메시지 구문 분석 차이를 악용하는 것입니다; 관련 요구사항은 HTTP/1.1에 관한 Section 6.3를 참조하십시오.

캐시의 주요 사용 목적 중 하나가 성능 최적화이기 때문에, 캐시 사용은 이전에 어떤 리소스가 요청되었는지에 대한 정보를 "유출"시킬 수 있습니다.

예를 들어, 사용자가 어떤 사이트를 방문하여 브라우저가 그 응답들을 캐시하고 나서 두 번째 사이트로 이동한 경우, 그 두 번째 사이트는 첫 번째 사이트에 존재하는 것을 알면서 응답을 로드하려 시도할 수 있습니다. 응답이 빠르게 로드되면 사용자가 해당 사이트 또는 특정 페이지를 방문한 것으로 추정할 수 있습니다.

이러한 "타이밍 공격"은 캐시 키에 참조 사이트의 정체성과 같은 추가 정보를 추가하여 완화할 수 있습니다(위에서 설명한 공격을 방지하기 위해). 이를 때때로 "이중 키화(double keying)"라고 합니다.

구현 및 배포상의 결함(종종 캐시 동작의 오해에서 비롯됨)은 민감한 정보(예: 인증 자격 증명)의 캐싱으로 이어질 수 있으며, 이는 원래 비공개로 간주되던 정보를 무단 당사자에게 노출시킬 수 있습니다.

Set-Cookie 응답 헤더 필드([COOKIE])가 캐싱을 차단하지 않는다는 점에 유의하십시오; Set-Cookie를 가진 캐시 가능 응답은 이후의 요청을 만족시키는 데 사용될 수 있습니다. 이러한 응답의 캐싱을 제어하려는 서버는 적절한 Cache-Control 응답 헤더 필드를 내보내는 것이 권장됩니다.

IANA는 "Hypertext Transfer Protocol (HTTP) Cache Directive Registry"를 업데이트했으며, 이는 섹션 5.2.4에 따른 등록 절차와 아래 표에 요약된 캐시 지시어 이름들을 포함합니다.

The Warning header field (and the warn codes that it uses) has been obsoleted for HTTP per [RFC9111].

9.1. 규범적 참고문헌

[HTTP]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022.

[RFC2119]

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC5234]

Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.

[RFC7405]

Kyzivat, P., “Case-Sensitive String Support in ABNF”, RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.

[RFC8174]

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. 정보성 참고문헌

[COOKIE]

Barth, A., “HTTP State Management Mechanism”, RFC 6265, DOI 10.17487/RFC6265, April 2011, <https://www.rfc-editor.org/info/rfc6265>.

[HTTP/1.1]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1”, STD 99, RFC 9112, DOI 10.17487/RFC9112, June 2022.

[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, DOI 10.17487/RFC2616, June 1999, <https://www.rfc-editor.org/info/rfc2616>.

[RFC5861]

Nottingham, M., “HTTP Cache-Control Extensions for Stale Content”, RFC 5861, DOI 10.17487/RFC5861, May 2010, <https://www.rfc-editor.org/info/rfc5861>.

[RFC7234]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.