Headers by Category — 손에 쥘 수 있는 taxonomy

"HTTP header 가 수백 개야. 외우지 마; 분류해. Header 가 어느 category 에 속하는지 알면 언제 expect 할지, 뭘 하는지 대충 알아."

95% 를 커버하는 다섯 category

IANA registry 에 수백 개 header 있고, 셀 수 없는 custom 도 있어. 목록 외우지 마. Category 를 외워 — 만나는 모든 header 가 이 다섯 양동이 중 하나에 들어가고, 양동이가 그게 뭘 하는지 알려줘:

Request control — client 가 server 한테 이 request 처리 방식 control 하려고 보냄. Host, Authorization, Accept, Accept-Encoding, Accept-Language, User-Agent, Cookie, Origin, Referer.
Response control — server 가 response 자체나 향후 request 에 대해 보냄. Server, Set-Cookie, WWW-Authenticate, Location, Vary, Allow, Retry-After.
Representation metadata — body 를 describe (request 든 response 든). Content-Type, Content-Length, Content-Encoding, Content-Language, Last-Modified, ETag. Body 와 같이 다님.
Caching & conditional — Request 와 response 를 bridge 해서 cache coordinate. Cache-Control, Expires, ETag (그래 ETag 가 두 category 에서 놀아), If-None-Match, If-Modified-Since, Vary. Track 5 가 여기 살아.
Connection & transport — Message 가 아니라 TCP 연결에 대한 것. Connection, Keep-Alive, Transfer-Encoding, Upgrade (WebSocket 으로 전환). HTTP/2 와 3 는 binary framing 으로 불필요해져서 대부분 떨궈.

실제 exchange 를 category 로 읽기

Category 가 머리에 들어오면 raw HTTP exchange 가 스스로 decode 돼. Request 보고 모든 header 분류하면 문서 안 읽고도 server 가 뭘 할지 예측 가능. Response 도 마찬가지 — 어떤 게 body-metadata 인지, cache 지시인지, session state 인지 알아.

Header 는 client 와 server 가 body 안 건드리고 negotiate 하는 방식이야. Content type, language, encoding, freshness, auth, session — 다 header 로 운반해서 body 는 실제 데이터에 자유. 이 중 뭐든 body 에 넣으려는 거 ("requested_language" 라는 JSON 필드) 는 protocol 과 싸우는 거야.

Custom header — X- 접두사는 잊어

수십 년 동안 custom header 가 X- 접두사를 달았어 (X-Request-ID, X-Forwarded-For). RFC 6648 (2012) 가 공식적으로 이 관례 은퇴시켰어. 오늘: 원하는 이름 골라, 단 descriptive 하게 (Pippa-Request-ID, Stripe-Signature, cf-ray). 많은 legacy X- header 가 여전히 현역 — X-Forwarded-For 가 어디나 있어 — 제거하면 client 깨지니까. 기존 거 rename 마; 그냥 자기 API 에 새 X- 추가하지 마.

cwkPippa 의 header 현실

전형적 cwkPippa request 는 category 1 에서 header 다섯 운반: Host: localhost:8000, Authorization: Bearer ..., Accept: application/json, Content-Type: application/json (POST 에), User-Agent. Response 는 representation metadata (Content-Type: application/json, Content-Length), connection control (Connection: keep-alive), 가끔 static asset 엔 Cache-Control 추가. SSE response 는 Content-Type: text/event-stream 에 Transfer-Encoding: chunked — type 이 브라우저한테 EventSource parser 쓰라 알려주고; encoding 이 body 가 고정 길이 없음을 알려줘.

Code

현실 request, 모든 header 분류됨·http

GET /api/conversations HTTP/1.1                  <- request line
Host: localhost:8000                             <- request control
Authorization: Bearer eyJhbGciOi...              <- request control
Accept: application/json                         <- request control (negotiation)
Accept-Encoding: gzip, br                        <- request control (negotiation)
Accept-Language: ko-KR, en-US;q=0.8              <- request control (negotiation)
User-Agent: cwkPippa-WebUI/1.0                   <- request control
Origin: http://localhost:5173                    <- request control (CORS)
Cookie: session=abc123                           <- request control (session)
Pippa-Request-ID: req_xyz789                     <- request control (custom)

짝 맞는 response — 다섯 category 다 등장·http

HTTP/1.1 200 OK                                  <- status line
Content-Type: application/json; charset=utf-8    <- representation metadata
Content-Length: 4823                             <- representation metadata
Content-Encoding: gzip                           <- representation metadata
ETag: "v17-abc123"                              <- representation + caching
Last-Modified: Sun, 25 May 2026 03:00:00 GMT     <- representation + caching
Cache-Control: private, max-age=60               <- caching
Vary: Accept-Encoding, Authorization             <- caching + response control
Set-Cookie: session=abc123; HttpOnly; Secure     <- response control
Server: uvicorn                                  <- response control
Connection: keep-alive                           <- connection
Pippa-Request-ID: req_xyz789                     <- custom (tracing 위해 echo)

Response 의 모든 header 를 프로그램으로 분류·python

import httpx

# 실제 exchange 의 모든 header 검사
resp = httpx.get('https://creativeworksofknowledge.com/')

print('--- response headers, 도착 순서 ---')
for key, value in resp.headers.items():
    print(f'{key}: {value}')

# 아는 것 분류
request_control = {'host', 'authorization', 'accept', 'accept-encoding',
                   'user-agent', 'cookie', 'origin', 'referer'}
representation  = {'content-type', 'content-length', 'content-encoding',
                   'content-language', 'last-modified', 'etag'}
caching         = {'cache-control', 'expires', 'if-none-match',
                   'if-modified-since', 'vary', 'age'}
response_ctrl   = {'server', 'set-cookie', 'www-authenticate', 'location',
                   'allow', 'retry-after'}
connection      = {'connection', 'keep-alive', 'transfer-encoding', 'upgrade'}

for key in resp.headers:
    lk = key.lower()
    if lk in representation: cat = 'representation'
    elif lk in caching:      cat = 'caching'
    elif lk in response_ctrl: cat = 'response-control'
    elif lk in connection:   cat = 'connection'
    else:                    cat = 'other/custom'
    print(f'{key:30s} -> {cat}')

Exercise

쉽게 칠 수 있는 API response 세 종류 골라: (1) JSON API (cwkPippa, GitHub, Stripe), (2) static asset (아무 이미지 URL), (3) streaming endpoint (네 backend 의 SSE 소스, 혹은 어느 AI 채팅 API). 각각의 모든 response header 를 나열하고 다섯 category 로 분류. 각 종류의 response 가 어느 category 에 기대? 어떤 header 가 특정 종류의 response 에만 나타나?

Hint

Static asset 은 caching 중심 (Cache-Control, ETag, Vary). JSON API 는 representation metadata + auth + custom tracing ID 에 기댐. Streaming endpoint 는 unique marker 있어: Content-Type: text/event-stream, Transfer-Encoding: chunked, 자주 Cache-Control: no-cache. 패턴이 문서 읽기 전에 endpoint 가 뭘 위한 건지 알려줘.

Headers by Category — 손에 쥘 수 있는 taxonomy

95% 를 커버하는 다섯 category

실제 exchange 를 category 로 읽기

Custom header — X- 접두사는 잊어

cwkPippa 의 header 현실

Code

External links

Exercise

Progress

댓글 0