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

- 원본 URL: https://datatracker.ietf.org/doc/html/rfc8594
- 아카이브 URL: (미수집)
- 저자/조직: IETF (Wilde)
- 발행일: 2019-05
- 마지막 확인일: 2026-05-27

## 핵심 인용 / 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 / 관련

- 같은 주제 다른 official-doc:
  - [[raw/official-docs/sunset-deprecation-headers-paired-usage]] — paired 사용 (RFC 8594 + RFC 9745 결합)
- canonical contract 섹션:
  - [[raw/project-notes/ca-skeleton-operational-contract]] — API compatibility / deprecation marker
- 대안 그룹: **Group G-F — API evolution & schema / API compatibility / deprecation**
- 본 source의 위치: `채택 근거: Sunset header (IETF RFC 8594) — ca-tmpl deprecation marker`