donghyeon.kang/llm-wiki
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Files
6c53ded9cb70f2d7cf3e66ff50d42f2d151c98b1
llm-wiki/vault/20-evidence/official-docs/compat-rfc-8594-sunset-header.md
T

7.3 KiB
Raw Blame History

title, source_type, url, archive_url, status, confidence, tags, related_projects, related_branches, created, last_reviewed
title source_type url archive_url status confidence tags related_projects related_branches created last_reviewed
RFC 8594 — The Sunset HTTP Header Field official-doc https://datatracker.ietf.org/doc/html/rfc8594 raw high
ca-tmpl
api-compatibility
deprecation
sunset-header
rfc8594
http
official-doc
official-standard
ca-skeleton-operational-contract
feature-api-compatibility-deprecation-contract
2026-05-22 2026-05-27

RFC 8594 — The Sunset HTTP Header Field

Layer: raw/official-docs/ — IETF Standards Track 표준 (RFC 8594, 2019-05) 원문 발췌. ca-tmpl 이 deprecation marker 로 채택한 Sunset 헤더의 정의를 확정. paired Deprecation 헤더 (RFC 9745) 와의 사용 관계는 raw/official-docs/sunset-deprecation-headers-paired-usage 에서 별도 다룸.

Parent / 활용 branch (필수)

Branch 이 자료가 정당화하는 결정
raw/branch-notes/feature-api-compatibility-deprecation-contract ca-tmpl 의 deprecation marker 중 Sunset 헤더 송신의 IETF 표준 근거 — 헤더 값 포맷 (HTTP-date) 과 의미 (decommissioning 시점) 의 1차 정의

컨텍스트 / 왜 저장했는지

ca-tmpl이 deprecation marker로 OpenAPI deprecated:true + Sunset header를 명시. 이 결정의 표준 근거가 RFC 8594. 헤더 값 포맷·의미·sunset link relation까지 확정해 두어야 verification suite가 OpenAPI diff + 응답 헤더 검사를 정확히 강제할 수 있음.

출처 / Source

핵심 인용 / Key quotes (verbatim)

[§Abstract] "This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future."

[§3] "Sunset = HTTP-date" (예: Sunset: Sat, 31 Dec 2018 23:59:59 GMT)

[§3] "The Sunset value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the future."

[§3] "Clients SHOULD treat Sunset timestamps as hints: it is not guaranteed that the resource will, in fact, be available until that time and will not be available after that time."

[§7.2] "Relation Name: sunset. Description: Identifies a resource that provides information about the context's retirement policy."

Claims Extracted / 추출된 주장

Claim ID Claim (이 자료가 직접 말하는 것) Evidence quote Strength Applies to Does not prove
RFC8594-C1 Sunset HTTP response header field 는 URI 가 특정 미래 시점에 unresponsive 가 될 가능성을 알리는 표준 메커니즘 [§Abstract] "This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future." official-standard HTTP/1.1+ 응답 "Sunset 시점에 client 가 자동으로 호출 중단해야 한다" 는 강제력은 본 spec 에 없음 — 단지 hint
RFC8594-C2 Sunset 값은 RFC 7231 §7.1.1.1 의 HTTP-date 포맷이며 미래 시점이어야 함 (SHOULD); 예: Sunset: Sat, 31 Dec 2018 23:59:59 GMT [§3] "Sunset = HTTP-date" + "The Sunset value is an HTTP-date timestamp, as defined in Section 7.1.1.1 of [RFC7231], and SHOULD be a timestamp in the future." official-standard Sunset 헤더 송신 시 UNIX epoch 또는 ISO 8601 사용은 본 spec 위반. Deprecation 헤더 (RFC 9745) 는 다른 포맷 (Structured Field Date) 사용에 주의
RFC8594-C3 client 는 Sunset timestamp 를 hint 로 취급해야 함 (SHOULD); 해당 시점 전까지의 가용성 또는 그 이후의 비가용성이 강제되지는 않음 [§3] "Clients SHOULD treat Sunset timestamps as hints: it is not guaranteed that the resource will, in fact, be available until that time and will not be available after that time." official-standard Sunset 헤더를 수신하는 client client 가 Sunset 시점을 무시해도 된다는 뜻은 아님 — SHOULD 수준의 hint 처리 권고
RFC8594-C4 sunset link relation 은 retirement policy 정보를 제공하는 리소스를 식별; Link header 의 rel="sunset" 으로 추가 문서 (마이그레이션 가이드 등) 를 가리킴 [§7.2] "Relation Name: sunset. Description: Identifies a resource that provides information about the context's retirement policy." official-standard Link header 와 함께 송신 시 link target 의 미디어 타입 / 포맷은 강제되지 않음

Usage Boundaries / 적용 경계

  • 이 자료가 직접 증명하는 것:
    • RFC8594-C1 ~ C3: Sunset 헤더의 정의, HTTP-date 포맷, client hint 시맨틱
    • RFC8594-C4: sunset link relation 의 IANA 등록 의미
  • 이 자료가 증명하지 않는 것:
    • Deprecation 헤더 (RFC 9745) 의 정의 — 본 spec 은 §1.4 use case 로만 deprecation 언급, 헤더 정의는 RFC 9745 별도
    • paired 사용 invariant (Sunset >= Deprecation) — RFC 9745 §4 에 정의됨 (별도 source 참조)
    • client 라이브러리가 Sunset 을 실제로 감지/경고하는 동작 — spec 은 SHOULD hint 만 권고, 구현은 vendor 별
    • migration window 의 적정 길이 (90d / 30d 등) — 본 spec 은 window 권고 없음
  • 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
    • ca-tmpl 의 Sunset 헤더 송신 위치 (Spring filter / interceptor / ControllerAdvice)
    • Sunset + Deprecation paired 송신은 raw/official-docs/sunset-deprecation-headers-paired-usage 의 결합 필요
    • OpenAPI deprecated: true + Sunset header + CI gate 의 verification suite 구성

메모 / Notes (내 프로젝트 해석)

본 섹션은 자료 직접 인용 아님. ca-tmpl 결정 컨텍스트 해석.

  • 헤더 값은 HTTP-date (예: Sat, 31 Dec 2018 23:59:59 GMT). UNIX timestamp 아님.
  • Sunset은 "예고"가 아니라 "이 시점 이후로는 unresponsive"의 의미. 즉 deprecate 시작 시점이 아니라 removal 시점.
  • 별도 IETF spec RFC 9745 (구 draft-ietf-httpapi-deprecation-header) 가 Deprecation 헤더를 정의. 관계는 Sunset >= Deprecation (Sunset 시점이 더 늦거나 같아야 함).
  • ca-tmpl 매핑:
    • Deprecation 헤더 = OpenAPI deprecated: true 표시와 같은 시점.
    • Sunset 헤더 = migration window(90d / 30d) 종료 시점.
    • 둘이 다른 의미이므로 동시에 보내야 정합.
  • Trade-off:
    • 표준 사용 장점: 외부 client 라이브러리(예: Spring HATEOAS, Apigee)가 헤더를 인식 가능. 운영 외부 통보 자동화에 활용.
    • 표준 사용 단점: 표준 자체는 client가 어떻게 행동해야 하는지 강제하지 않음. 헤더만으로는 강제력 없음.
    • 결론: ca-tmpl처럼 OpenAPI deprecated:true + breaking diff CI gate + 응답 헤더 3중을 함께 써야 강제력 확보.

Related / 관련

Reference in New Issue View Git Blame Copy Permalink