donghyeon.kang/llm-wiki

Fork 0

Files

T

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

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

8.8 KiB

Raw Permalink Blame History

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

title

source_type

url

archive_url

related_branches

related_projects

IETF RFC 9112 — HTTP/1.1 §7.1 Chunked Transfer Coding

Layer: raw/official-docs/ — IETF RFC 9112 (June 2022, Internet Standard) §7 Transfer Codings + §7.1 Chunked Transfer Coding 발췌. Strength 분류: official-standard — IETF Internet Standard (STD 99). RFC 7230 을 obsolete. 검증된 요약은 /ingest 후 wiki/concepts/ 에 별도 작성.

Parent / 활용 branch (필수)

Branch	이 자료가 정당화하는 결정
raw/branch-notes/feature-streaming-response-contract	Chunked Transfer Encoding alternative 의 프로토콜 명세 근거 — §7.1 chunked-body grammar, unknown-size content stream 전송 메커니즘, trailer section, HTTP/1.1 한정 동작

출처 / Source

원본 URL: https://www.rfc-editor.org/rfc/rfc9112.html
Datatracker URL: https://datatracker.ietf.org/doc/html/rfc9112
아카이브 URL: (미수집)
저자 / 조직: IETF — R. Fielding (Adobe), M. Nottingham (Fastly), J. Reschke (greenbytes)
발행일: 2022-06 (June 2022, Internet Standard / STD 99)
Obsoletes: RFC 7230
마지막 확인일: 2026-06-02

왜 저장했는지 / Why archived

feature-streaming-response-contract 에서 Chunked Transfer Encoding 은 별도 프로토콜 없이 HTTP/1.1 표준만으로 streaming 을 구현하는 alternative. RFC 9112 §7.1 은 chunked 의 ABNF grammar, MUST 요구사항, trailer section 을 normative 하게 정의. "size 를 모르는 content 를 스트리밍할 수 있다" claim 의 official-standard 근거이자, HTTP/1.1 한정 동작 (HTTP/2·HTTP/3 에서는 다름) 확인.

핵심 인용 / Key quotes (verbatim)

[Abstract] "This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns."

[§7 Transfer Codings] "Transfer coding names indicate an encoding transformation that has been, can be, or might need to be applied to a message's content in order to ensure 'safe transport' through the network."

[§7.1 Chunked Transfer Coding] "The chunked transfer coding wraps content in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields."

[§7.1 Chunked Transfer Coding, purpose] "chunked encoding enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to retain connection persistence and the recipient to know when it has received the entire message."

[§7.1 Chunked Transfer Coding, ABNF]

chunked-body   = *chunk
                 last-chunk
                 trailer-section
                 CRLF

chunk          = chunk-size [ chunk-ext ] CRLF
                 chunk-data CRLF
chunk-size     = 1*HEXDIG
last-chunk     = 1*("0") [ chunk-ext ] CRLF

chunk-data     = 1*OCTET ; a sequence of chunk-size octets

[§7.1 Chunked Transfer Coding, requirements] "a recipient MUST be able to parse and decode the chunked transfer coding"

[§7.1 Chunked Transfer Coding, no double-chunking] "A sender MUST NOT apply the chunked transfer coding more than once to a message body"

[§7.1.2 Chunked Trailer Section] "a trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might be dynamically generated while the content is sent, such as a message integrity check, digital signature, or post-processing status."

Claims Extracted / 추출된 주장

Claim ID	Claim (이 자료가 직접 말하는 것)	Evidence quote	Strength	Applies to	Does not prove
RFC9112-CHUNK-C1	Chunked transfer coding 은 크기를 알 수 없는 content stream 을 length-delimited buffer 의 연속으로 전송하여, 전체 크기 없이도 connection 을 유지하며 메시지 완료를 수신자가 알 수 있게 한다	[§7.1] "enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to retain connection persistence and the recipient to know when it has received the entire message."	`official-standard`	HTTP/1.1 메시지 framing — `Transfer-Encoding: chunked` 헤더 사용 시	HTTP/2 · HTTP/3 에 직접 적용되지 않음 — HTTP/2 는 DATA frame 으로 별도 framing. `Transfer-Encoding` 헤더 자체가 HTTP/2 에서 금지됨 (RFC 9113 §8.2.2)
RFC9112-CHUNK-C2	Chunked-body 의 마지막 chunk 는 chunk-size = 0 (`last-chunk`) 으로 표시되며, 이후 trailer-section 과 CRLF 가 따름	[§7.1 ABNF] "last-chunk = 1*("0") [ chunk-ext ] CRLF"	`official-standard`	HTTP/1.1 chunked 응답을 파싱하는 모든 구현	Chunk 순서의 의미 론적 보장 (순서 보존 의무는 TCP 에서 제공, HTTP 는 별도 언급 없음)
RFC9112-CHUNK-C3	수신자는 chunked transfer coding 을 반드시 파싱·디코딩할 수 있어야 한다 (MUST)	[§7.1] "a recipient MUST be able to parse and decode the chunked transfer coding"	`official-standard`	HTTP/1.1 을 구현하는 모든 클라이언트 (브라우저 포함)	HTTP/2 클라이언트가 chunked 를 이해해야 한다는 뜻은 아님
RFC9112-CHUNK-C4	동일 message body 에 chunked 를 두 번 이상 적용하는 것은 금지 (MUST NOT)	[§7.1] "A sender MUST NOT apply the chunked transfer coding more than once to a message body"	`official-standard`	Transfer-Encoding 헤더 조합 시	다른 encoding (gzip 등) 과의 조합 금지를 뜻하는 것은 아님 — chunked 를 마지막 encoding 으로 적용하는 조합은 허용
RFC9112-CHUNK-C5	Trailer section 은 동적으로 생성된 메타데이터(무결성 검사, 디지털 서명, 후처리 상태 등)를 메시지 끝에 포함하기 위해 사용	[§7.1.2] "a trailer section allows the sender to include additional fields at the end of a chunked message in order to supply metadata that might be dynamically generated while the content is sent, such as a message integrity check, digital signature, or post-processing status."	`official-standard`	chunked 응답에서 trailing 메타데이터가 필요한 경우	Trailer 사용이 브라우저에서 광범위하게 지원된다는 뜻은 아님 — 브라우저 지원은 별도 확인 필요

Usage Boundaries / 적용 경계

이 자료가 직접 증명하는 것:
- C1: Chunked 는 HTTP/1.1 표준 메커니즘으로 미리 알 수 없는 크기의 content 를 streaming 할 수 있음
- C2, C3: Chunked 는 HTTP/1.1 을 지원하는 모든 클라이언트가 반드시 처리 가능
- C4: Double-chunking 금지 — Transfer-Encoding 체이닝 시 주의
- C5: Trailer section 은 동적 메타데이터를 후미에 첨부하는 공식 방법
이 자료가 증명하지 않는 것:
- Spring StreamingResponseBody 가 자동으로 Transfer-Encoding: chunked 를 사용한다는 주장 — Servlet 컨테이너 동작 의존 (Spring vendor doc 별도)
- HTTP/2 환경에서 chunked 가 동일하게 동작한다는 주장 — HTTP/2 는 이 메커니즘을 사용하지 않음
- Nginx 등 reverse proxy 가 chunked 를 클라이언트에 그대로 전달한다는 주장 — proxy_buffering 설정 영향
내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-skeleton 의 embedded Tomcat 이 StreamingResponseBody 응답에 Transfer-Encoding: chunked 를 자동 적용하는지
- reverse proxy (Nginx) 의 proxy_buffering off 설정이 없으면 chunked streaming 이 클라이언트에 도달하지 못하는 버퍼링 문제

메모 / Notes

C1 은 ca-skeleton 에서 chunked 를 "별도 프로토콜 없는 가장 단순한 streaming" alternative 로 채택할 수 있는 official-standard 근거
HTTP/2 에서 Transfer-Encoding: chunked 헤더 자체가 금지되는 점 (RFC 9113 §8.2.2) 은 본 문서 범위 밖 — 별도 확인 필요
C5 의 trailer section 은 Spring MVC 의 일반적 streaming 패턴에서는 잘 사용되지 않음 (브라우저 지원 불균일)

같은 주제 다른 raw 자료: raw/official-docs/whatwg-html-server-sent-events (SSE — application-level streaming 프로토콜)
같은 주제 다른 raw 자료: raw/official-docs/rfc6455-websocket (WebSocket — TCP-based 별도 프로토콜)
같은 주제 다른 raw 자료: raw/official-docs/rfc9110-http-semantics (HTTP semantics — 상위 계층)
인용하는 branch: raw/branch-notes/feature-streaming-response-contract

8.8 KiB Raw Permalink Blame History