8.3 KiB
8.3 KiB
title, source_type, url, archive_url, vendor, related_branches, related_projects, tags, created
| title | source_type | url | archive_url | vendor | related_branches | related_projects | tags | created | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RFC 9457 — Problem Details for HTTP APIs (IETF Standards Track, July 2023) | official-doc | https://www.rfc-editor.org/rfc/rfc9457.html | IETF / M. Nottingham, E. Wilde, S. Dalal |
|
|
|
2026-06-15 |
RFC 9457 — Problem Details for HTTP APIs (IETF Standards Track, July 2023)
Layer:
raw/— 외부 자료(공식 문서 / 표준 사양)의 원문 발췌·출처 기록. 검증된 요약은/ingest후wiki/concepts/에 별도 작성. 원본은 raw에 영구 보관.
Parent / 활용 branch (필수, 최소 1개+)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-contract-registry-governance | D5: 외부 platform 표준(RFC 7807→9457)을 사용하는 경우에도 skeleton registry 에 mapping/version row 를 남겨야 함 — RFC 9457 이 RFC 7807 을 obsolete 하고 error envelope shape 을 변경한다는 IETF 공식 증거 |
출처 / Source
- 원본 URL: https://www.rfc-editor.org/rfc/rfc9457.html
- 아카이브 URL: (미제공)
- 저자 / 조직: M. Nottingham, E. Wilde, S. Dalal — IETF Standards Track
- 발행일: July 2023
- 마지막 확인일: 2026-06-15
왜 저장했는지 / Why archived
RFC 9457 은 RFC 7807 을 obsolete 하고 error envelope 의 외부 표준이 버전 관리된다는 사실을 공식으로 증명한다. feature-contract-registry-governance 브랜치의 D5 결정 — "외부 platform 표준을 쓰는 경우에도 skeleton registry 에 mapping row 를 남김" — 이 UNSUPPORTED_DECISION 으로 표시된 것을 RFC 9457 원문 인용으로 뒷받침하기 위해 보관.
핵심 인용 / Key quotes (verbatim, 3~5문장)
[Abstract] "This document obsoletes RFC 7807."
[§3.1.1 — line 250] "Consumers MUST use the "type" URI (after resolution, if necessary) as the problem type's primary identifier."
[§3 — line 378] "Clients consuming problem details MUST ignore any such extensions that they don't recognize; this allows problem types to evolve and include additional information in the future."
[§4.2 — line 469] "This specification defines the "HTTP Problem Types" registry for common, widely used problem type URIs, to promote reuse."
[Appendix D — line 808] "Section 4.2 introduces a registry of common problem type URIs"
Claims Extracted / 추출된 주장
이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기 쓰지 않는다.
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| RFC9457-C1 | RFC 9457 은 RFC 7807 을 공식 폐지(obsolete)하며 HTTP API error response 의 외부 표준이 버전 관리된다 | [Abstract] "This document obsoletes RFC 7807." | official-standard |
IETF Standards Track 을 따르는 모든 HTTP API error response 설계 | RFC 7807 → 9457 외 에도 추가 개정이 없을 것이라는 보장 없음; ca-tmpl 의 기존 RFC 7807 기반 error 코드가 자동으로 9457 호환이 됨을 증명하지 않음 |
| RFC9457-C2 | 소비자(consumer)는 반드시 type URI 를 problem type 의 **기본 식별자(primary identifier)**로 사용해야 한다 |
[§3.1.1] "Consumers MUST use the "type" URI (after resolution, if necessary) as the problem type's primary identifier." | official-standard |
RFC 9457 을 준수하는 모든 HTTP API 클라이언트 및 서버 구현 | server 측의 type URI 선택 방식(resolvable vs non-resolvable)을 규정하지 않음; 특정 프레임워크(Spring, etc.)의 기본 error 응답이 이 rule 을 준수하는지 증명하지 않음 |
| RFC9457-C3 | 소비자는 인식하지 못하는 extension member 를 반드시 무시해야 한다(forward-compatibility 규칙) | [§3] "Clients consuming problem details MUST ignore any such extensions that they don't recognize; this allows problem types to evolve and include additional information in the future." | official-standard |
RFC 9457 을 준수하는 클라이언트 구현체; extension member 를 추가하는 server 설계 | server 측이 어떤 extension 을 추가해도 된다는 것을 무한정 허용하지 않음; IANA registry 에 없는 extension 의 의미론적 안전성은 보장하지 않음 |
| RFC9457-C4 | IETF 는 RFC 9457 과 함께 "HTTP Problem Types" IANA registry 를 신설했다 | [§4.2] "This specification defines the "HTTP Problem Types" registry for common, widely used problem type URIs, to promote reuse." | official-standard |
HTTP API 의 error type URI 재사용을 원하는 모든 구현자 | registry 등록이 의무(MUST)임을 규정하지 않음; vendor-specific / application-specific / deployment-specific 값은 등록 불가(§4.2 본문) |
| RFC9457-C5 | RFC 9457 이 RFC 7807 대비 도입한 3가지 변경은 (1) common problem type URI 의 registry 신설, (2) 다수 문제(multiple problems) 처리 방식 명확화, (3) 역참조 불가 type URI 에 대한 안내 추가다 | [Appendix D] "Section 4.2 introduces a registry of common problem type URIs" [...] "Section 3 clarifies how multiple problems should be treated" [...] "Section 3.1.1 provides guidance for using type URIs that cannot be dereferenced" | official-standard |
RFC 7807 → 9457 마이그레이션을 고려하는 API 설계자 | error envelope 의 필드 추가·삭제가 없었음을 의미하지 않음(type/status/title/detail/instance 5 멤버는 유지되지만 semantic 변경 가능); 특정 언어/프레임워크 구현체의 migration 가이드를 제공하지 않음 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
RFC9457-C1: HTTP API error response 의 외부 표준이 개정될 수 있으며 RFC 7807 은 이미 obsolete — skeleton registry 에 version/mapping row 가 필요한 이유RFC9457-C2: error envelope 의typeURI 가 primary identifier 이며 소비자는 이것으로 problem type 을 식별해야 함RFC9457-C3: extension member 를 추가해도 forward-compatible 하게 설계할 수 있음 — registry 에 새 column 추가 시 소비자 영향 최소화 가능RFC9457-C4: 표준 error type URI 재사용을 위한 IANA registry 가 존재함RFC9457-C5: RFC 7807 → 9457 의 3가지 구체적 변경 사항
- 이 자료가 증명하지 않는 것:
- RFC 9457 이 RFC 7807 과 필드 레벨에서 하위 호환임을 보장하지 않음 — migration 검증은 별도 필요
- Spring Boot / Keycloak 등 특정 구현체가 RFC 9457 을 자동으로 준수하는지 증명하지 않음
- ca-tmpl 의 현재 error response 가 RFC 9457 compliant 한지 증명하지 않음
- registry 에 외부 표준 mapping row 를 어떤 schema 로 추가해야 하는지 안내하지 않음 (D4 UNSUPPORTED_DECISION 영역)
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 error response envelope 이 RFC 9457 의
type/status/title/detail/instance구조를 따르는지 코드 검증 - Spring Boot
ProblemDetail(Spring 6+) 의 RFC 9457 준수 여부 공식 문서 확인 (별도 raw 자료 필요) - registry 의
compatibility_impactcolumn 이 RFC 9457 obsolete 처리를 어떻게 반영할지 결정 (D4 UNSUPPORTED_DECISION 범위)
- ca-tmpl 의 error response envelope 이 RFC 9457 의
메모 / Notes
- RFC 9457 의 IANA "HTTP Problem Types" registry URL: https://iana.org/assignments/http-problem-types
- Appendix D 의 3가지 변경 중 "(2) multiple problems" 는 §3 에서 단일 response 에 여러 problem 을 담는 방법을 안내 — ca-tmpl 의 validation error 처리(복수 field 오류 시 어떻게 encapsulate 할지)에 직접 관련
RFC9457-C3(forward-compatibility MUST ignore) 는 ca-tmpl registry 의 extension column 추가 시 소비자 영향을 제한하는 근거로 활용 가능 — 단 UNSUPPORTED_IMPL_DECISION 없이 직접 결론 내리지 말 것
Related / 관련
- 같은 주제 다른 official-doc: raw/official-docs/opentelemetry-versioning-stability-spec — 외부 표준 versioning 일반 패턴
- 이 자료를 인용한 branch-note: raw/branch-notes/feature-contract-registry-governance (D5)
- wiki 요약 (생성 시):
[[wiki/concepts/rfc9457-problem-details]](미생성)