donghyeon.kang/llm-wiki

Fork 0

Files

T

DongHyeonka d71669eb59 fix: 하네스 제거 및 keycloak 문서 보강

2026-07-25 12:53:13 +09:00

9.3 KiB

Raw Blame History

title, source_type, url, archive_url, related_branches, related_projects, tags, created

title

source_type

url

archive_url

related_branches

related_projects

RFC 3986 — URI Generic Syntax

Layer: raw/ — 외부 자료(공식 문서)의 원문 발췌·출처 기록. 검증된 요약은 /ingest 후 wiki/concepts/에 source-summary-template 형식으로 별도 작성. 원본은 raw에 영구 보관.

Parent / 활용 branch (필수, 최소 1개+)

이 자료는 혼자 존재하지 않는다. 어느 branch의 구현 결정의 근거로서 보관됨.

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-resource-identifier-contract	D2 (charset / encoding) — URL path 에서 안전한 문자 집합 정의 + D3 (URL-safe + case sensitivity) — `unreserved` 문자 집합 정의 및 scheme·host 는 case-insensitive, path 는 case-sensitive 라는 normalization 규칙

출처 / Source

원본 URL: https://www.rfc-editor.org/rfc/rfc3986
아카이브 URL: (미설정)
저자 / 조직: Tim Berners-Lee, Roy T. Fielding, Larry Masinter — IETF (Internet Engineering Task Force)
발행일: January 2005 (Standards Track, STD 66)
마지막 확인일: 2026-05-31

왜 저장했는지 / Why archived

ca-skeleton 의 resource ID 형식 결정 (branch: feature-resource-identifier-contract) 에서 URL path 에 허용된 문자 집합과 대소문자 정규화 규칙을 normative standard 로 확정해야 한다. RFC 3986 은 URI generic syntax 의 IETF 표준 사양이며, unreserved 문자 집합 (ALPHA / DIGIT / "-" / "." / "_" / "~") 과 path component 의 case-sensitivity 정책을 규범적으로 정의하므로 D2·D3 결정의 최고 등급 근거(official-standard)로 보관한다.

핵심 인용 / Key quotes (verbatim, 5문장)

[§2.3] "Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde."

[§2.3 ABNF] unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

[§2.2] "URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications."

[§6.2.2.1] "When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase."

[§6.2.2.1] "The other generic syntax components are assumed to be case-sensitive unless specifically defined otherwise by the scheme (see Section 6.2.3)."

Claims Extracted / 추출된 주장

이 자료가 직접 말하는 것만 claim 으로 분리한다. 내 프로젝트에 적용한 결론은 여기에 쓰지 않는다.

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
RFC3986-C1	URI 에서 예약 목적 없이 사용할 수 있는 문자(unreserved)는 ALPHA, DIGIT, 하이픈, 마침표, 밑줄, 물결표이며 ABNF 로 `ALPHA / DIGIT / "-" / "." / "_" / "~"` 로 정의된다	[§2.3] "Characters that are allowed in a URI but do not have a reserved purpose are called unreserved. These include uppercase and lowercase letters, decimal digits, hyphen, period, underscore, and tilde." + ABNF `unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"`	`official-standard`	RFC 3986 을 따르는 모든 URI	base64 표준(+, /, =), base62(대소문자+숫자만) 등 다른 encoding 의 URL-safety 를 직접 평가하지 않음
RFC3986-C2	reserved 문자를 percent-encode 하거나 reserved 문자에 해당하는 percent-encoded octet 을 decode 하면 URI 의 의미가 달라진다	[§2.2] "URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Percent-encoding a reserved character, or decoding a percent-encoded octet that corresponds to a reserved character, will change how the URI is interpreted by most applications."	`official-standard`	URI 에서 gen-delims / sub-delims 를 데이터로 사용해야 하는 모든 경우	reserved 문자의 구체적인 처리 방식(scheme-specific 허용 여부)은 각 scheme 사양에서 정의됨
RFC3986-C3	URI path component (및 기타 generic syntax component) 는 scheme 이 달리 정의하지 않는 한 case-sensitive 로 가정해야 한다	[§6.2.2.1] "The other generic syntax components are assumed to be case-sensitive unless specifically defined otherwise by the scheme (see Section 6.2.3)."	`official-standard`	HTTP(S) URI path 를 비교·normalize 해야 하는 모든 구현	scheme 이 명시적으로 case-insensitive 를 선언한 component 에는 적용되지 않음
RFC3986-C4	scheme 과 host component 는 case-insensitive 이므로 lowercase 로 normalize 해야 한다	[§6.2.2.1] "When a URI uses components of the generic syntax, the component syntax equivalence rules always apply; namely, that the scheme and host are case-insensitive and therefore should be normalized to lowercase."	`official-standard`	모든 RFC 3986 준수 URI 구현	path / query / fragment 에는 이 case-insensitive 규칙이 적용되지 않음
RFC3986-C5	URI path 의 pchar 는 unreserved / pct-encoded / sub-delims / ":" / "@" 로 구성된다	[§3.3 ABNF] `pchar = unreserved / pct-encoded / sub-delims / ":" / "@"`	`official-standard`	URI path segment 에 포함될 수 있는 문자를 결정해야 하는 구현	pchar 에 sub-delims (!, $, &, ' 등) 포함이 허용된다고 해서 resource ID 에 자유롭게 사용해도 됨을 의미하지 않음 — ID 의 ID format policy 는 별도 결정 필요

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- RFC3986-C1: URL path 에 percent-encoding 없이 안전하게 사용할 수 있는 문자는 정확히 ALPHA / DIGIT / "-" / "." / "_" / "~" 임.
- RFC3986-C2: +, /, = (base64 standard charset) 는 reserved 또는 non-unreserved 문자이므로 path segment 에 raw 사용 불가. URL-safe base64 (-, _) 는 unreserved 에 포함됨.
- RFC3986-C3: HTTP URI path (resource ID 포함) 는 case-sensitive 이며, abc 와 ABC 는 다른 자원을 가리킬 수 있음.
- RFC3986-C4: http:// 와 HTTP://, example.com 과 EXAMPLE.COM 은 동등하게 정규화되어야 함.
- RFC3986-C5: path segment 에 허용되는 전체 문자 집합의 상한(pchar).
이 자료가 증명하지 않는 것:
- 특정 ID format (UUID, ULID, NanoID 등) 중 무엇을 선택해야 하는지 — 그것은 ID format policy 결정.
- base32 Crockford 나 base62 같은 encoding 이 RFC 3986 unreserved charset 의 부분집합인지 — 추가 분석 필요 (단, RFC3986-C1 의 chareset 정의로 부분집합 여부 판정 가능).
- case-insensitive ID format (예: ULID base32) 을 lowercase normalize 해야 하는지 여부 — RFC 는 path 가 case-sensitive 라고만 말하며, 어플리케이션 레벨 normalize 정책은 추가 결정 사항.
- percent-encoding 을 실제로 수행해야 하는 시점의 구체적인 구현 방법.
ca-skeleton 에 적용하려면 추가 확인이 필요한 것:
- ULID 의 Crockford base32 charset (0-9A-Z, case-insensitive) 이 RFC3986-C1 unreserved 의 부분집합임을 확인 (ALPHA + DIGIT 이므로 부분집합이지만, uppercase 고정 시 path case-sensitive 규칙과의 정합 확인 필요).
- NanoID 기본 charset (A-Za-z0-9_-) 이 RFC3986-C1 unreserved 의 부분집합임을 확인 (_, - 포함이므로 부분집합).
- base64 standard (+/=) 를 포함하는 ID format 사용 금지 — RFC3986-C1·C2 로 직접 차단.

메모 / Notes

RFC 3986 은 2005년 발행 STD 66 으로, 현재까지 HTTP URI 의 normative standard. HTTP/1.1, HTTP/2, HTTP/3 모두 이 spec 을 참조함.
unreserved charset 에 ~ (tilde) 가 포함되어 있음 — 일부 legacy 구현이 %7E 로 인코딩하는 경우가 있으나 RFC3986-C1 에 따르면 decode 되어야 함 (§6.2.2.2 Percent-Encoding Normalization 참조).
path 의 경우 pchar (C5) 에 sub-delims 포함이 허용되지만, resource ID 는 delimiter 로 오해될 가능성을 배제하기 위해 unreserved charset 만 사용하는 것이 safe subset 전략.
추가로 봐야 할 동일 출처 섹션: §6.2.2.2 Percent-Encoding Normalization (unreserved 문자의 percent-encoded octet decode 권고), §6.2.2.3 Path Segment Normalization (dot-segment 제거).

같은 주제 다른 official-doc (예정):
- raw/official-docs/rfc9562-uuid.md — UUID v4·v7 format spec (D1 결정 근거)
- raw/official-docs/ulid-spec.md — ULID 26자 base32 + monotonic spec (D1 결정 근거)
- raw/official-docs/google-aip-122-resource-names.md — Google AIP-122 resource name 정책 (D6 prefix 정책 참조)
이 자료를 인용할 wiki 요약: wiki/concepts/uri-charset-and-case-normalization (생성 시)

9.3 KiB Raw Blame History