대상화된 HTTP 캐시 제어

이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"과 같은 핵심 용어는, 모두 대문자로 표기된 경우에 한해 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석되어야 합니다.

대상화된 필드는 Dictionary Structured Fields(Section 3.2 of [STRUCTURED-FIELDS])입니다. Dictionary의 각 멤버는 캐시 응답 지시어(Section 5.2.2 of [HTTP-CACHING])와 확장 응답 지시어(Section 5.2.3 of [HTTP-CACHING])를 포함합니다. 대상화된 필드는 종종 Cache-Control 필드와 동일한 문법을 가지지만, 오류 처리 차이로 인해 Cache-Control 파서를 사용하면 Structured Fields 파서를 사용하는 것과 상호운용성 문제를 일으킬 수 있습니다.

캐시 지시어 값은 구조화된 데이터 타입으로 정의되어 있지 않으므로, 해당 값을 적절한 타입으로 매핑할 필요가 있습니다. 섹션 5.2은 캐시 지시어 값이 없거나, 인용 문자열(quoted-string) 또는 토큰(token)이라고 정의합니다.

따라서 값이 없는 캐시 지시어는 Boolean으로 매핑됩니다(Section 3.3.6 of [STRUCTURED-FIELDS]). 값이 인용 문자열이면 String으로(Section 3.3.3) 매핑되고, 토큰이면 Token(Section 3.3.4), Integer(Section 3.3.1), 또는 Decimal(Section 3.3.2)로 매핑됩니다. 이는 값의 내용에 따라 달라집니다.

예를 들어, max-age 지시어(Section 5.2.2.1)는 정수 값을 가지며; no-store(Section 5.2.2.5)는 항상 Boolean true 값을 가지며, no-cache(Section 5.2.2.4)는 Boolean true 이거나 쉼표로 구분된 필드 이름 목록을 포함하는 문자열이 될 수 있습니다.

구현은 이러한 추론된 제약을 위반하는 값을 생성해서는 안됩니다. 특히, 첫 문자가 알파벳 또는 "*"가 아닌 문자열 값은 다른 타입으로 오해되지 않도록 반드시 String으로 생성되어야 합니다.

구현은 이러한 제약을 위반하는 값을 수용해서는 안됩니다. 예를 들어, 소수(decimal) 값을 가진 max-age를 정수로 강제 변환하는 수용 구현은 다른 구현과 다르게 동작하여 상호운용성 문제를 일으킬 수 있습니다.

캐시 지시어에 수신된 파라미터는 다른 처리가 명시되지 않는 한 무시되어야 합니다.

특정 응답의 대상화된 필드가 비어 있거나 파싱 오류가 발생하면, 해당 필드는 캐시에 의해 무시되어야 합니다(즉, 필드가 없는 것처럼 동작하며, 다른 cache-control 메커니즘으로 폴백할 가능성이 큽니다).

이 명세를 구현하는 캐시는 대상 리스트(target list)를 유지합니다. 대상 리스트는 캐싱 정책에 사용되는 대상화된 필드 이름의 순서 있는 목록이며, 순서는 가장 적용 가능성이 높은 것에서 가장 낮은 것으로 우선순위를 반영합니다. 대상 리스트는 고정되거나 사용자 구성 가능하거나 구현에 따라 요청별로 생성될 수 있습니다.

  [ExampleCDN-Cache-Control, CDN-Cache-Control]
  

이 명세를 구현하는 캐시가 대상 리스트에 있는 하나 이상의 헤더 필드 이름을 가진 응답을 수신하면, 캐시는 유효하고 비어 있지 않은 값이 있는 리스트상의 첫 번째(대상 리스트 순서 기준) 필드를 선택하여 그 값을 응답의 캐싱 정책을 결정하는 데 사용해야 하며, 리스트상의 필드들에서 유효한 비어 있지 않은 값이 없을 경우를 제외하고는 해당 응답의 Cache-Control 및 Expires 헤더 필드를 무시해야 합니다.

이는 응답별로 발생한다는 점에 유의하십시오; 캐시의 대상 리스트에 어떤 멤버도 존재하지 않거나 유효하지 않거나 비어 있지 않다면, 캐시는 HTTP에 따라 요구되는 다른 캐시 제어 메커니즘으로 폴백합니다([HTTP-CACHING]).

캐시의 대상 리스트에 없는 대상화된 필드는 해당 캐시의 동작을 변경해서는 안되며, 통과(pass-through)되어야 합니다.

• max-age
• must-revalidate
• no-store
• no-cache
• private

또한, 캐시는 Cache-Control 응답 헤더 필드에서 지원하는 다른 캐시 지시어들(확장 캐시 지시어 포함)을 구현하는 것이 권장됩니다.

대상화된 필드 내 캐시 지시어의 의미와 우선순위는 Cache-Control의 것과 동일합니다. 특히 no-store와 no-cache는 max-age를 무력화하며, 인식되지 않는 확장 지시어는 무시됩니다.

HTTP 캐싱은 섹션 4.2에 정의된 단일 종단 간(end-to-end) 신선도 모델을 가집니다. 추가적인 신선도 메커니즘이 요청 경로상의 일부 캐시에만 제공되는 경우(예: 대상화된 필드 사용) 이들 간의 상호작용을 신중히 고려해야 합니다. 특히 대상화된 캐시는 다른 캐시보다 더 긴 신선도 수명을 가질 수 있어, 다른 캐시에게는 해당 응답이 조기에(또는 즉시) 만료된 것으로 보이는 상황을 만들 수 있으며, 이는 캐시 효율성에 부정적 영향을 미칠 수 있습니다.

Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600

CDN 관점에서는 이 응답이 캐시된 지 30분 후에도 여전히 신선하지만, 다른 캐시 관점에서는 이미 만료된 상태입니다. 자세한 논의는 [AGE-PENALTY]를 참조하십시오.

• Age 헤더 필드 제거
• Date 헤더 필드 값을 현재 시각으로 갱신
• Expires 헤더 필드 값을 현재 시각 + Cache-Control: max-age 값으로 갱신

이 명세서는 이러한 효과를 완화하기 위한 구현상의 특정 요구사항을 부과하지 않지만, 대상화된 필드의 정의에서 이를 규정할 수 있습니다.

특정 클래스의 캐시에 대한 대상화된 필드는 "Hypertext Transfer Protocol (HTTP) Field Name Registry"(<https://www.iana.org/assignments/http-fields/>)에 등록을 요청하여 정의할 수 있습니다.

등록 요청은 본 문서를 명세 문서로 사용할 수 있으며, 이 경우 Comments 필드에 대상화된 필드가 적용되는 캐시 클래스가 명확히 정의되어야 합니다. 또는 해당 필드를 정의하는 다른 문서가 존재한다면 그것을 명세 문서로 사용할 수 있습니다.

관례적으로 대상화된 필드는 접미사 "-Cache-Control"을 가집니다(예: "ExampleCDN-Cache-Control"). 그러나 이 접미사만으로 대상화된 필드를 식별해서는 안됩니다; 이는 단지 관례일 뿐입니다.

Cache-Control: max-age=60, s-maxage=120
CDN-Cache-Control: max-age=3600

CDN-Cache-Control: max-age=600
Cache-Control: no-store

Cache-Control: no-store

Cache-Control: no-store
CDN-Cache-Control: none

(참고: 'none'은 등록된 캐시 지시어가 아니며, 비어 있는 값을 가진 헤더 필드를 보내어 무시되는 상황을 피하기 위해 여기 사용되었습니다.)