HTTP 헤더 파서

네. 파서는 첫 줄을 기준으로 입력이 HTTP 요청인지 응답인지 자동 감지해 그에 맞게 파싱합니다. 요청 라인은 HTTP 메서드(GET, POST 등)로 시작하고, 응답 라인은 HTTP/version으로 시작합니다.

네. Set-Cookie 헤더는 개별 쿠키로 파싱되어 이름, 값, 그리고 HttpOnly, Secure, SameSite, Path, Domain, Max-Age 같은 모든 플래그를 보여줍니다.

한 줄에 하나의 헤더가 "Name: Value" 형태로 있는 표준 HTTP/1.1 및 HTTP/2 헤더 형식입니다. 브라우저 개발자 도구에서 직접 헤더를 복사할 수 있습니다.

요청에는 보통 host, user-agent, accept, accept-encoding, cookie가 담기고; 응답은 content-type, content-length, cache-control, set-cookie, date로 답합니다. API 트래픽은 들어갈 때 authorization과 content-type: application/json을 더하고, 나올 때 rate-limit 헤더를 더합니다. RFC 9110(HTTP semantics, 2022)이 이 모두를 정의하는 현대 참조 문서입니다.

요청 헤더(host, authorization, accept-*)는 클라이언트가 원하는 것을 설명하고; 응답 헤더(location, set-cookie, retry-after)는 무엇이 돌아왔는지 설명합니다. 일부 필드는 양방향에 나타나고(cache-control, content-type), 몇몇은 메시지 내용이 아니라 연결 자체를 다룹니다(connection: keep-alive). 이 파서는 각 헤더가 어느 쪽인지 표시합니다.

RFC 9110에 따르면 반복되는 대부분의 필드는 하나의 쉼표 구분 목록으로 합쳐집니다 - cache-control 두 줄과 no-cache, no-store라고 적힌 한 줄은 동등합니다. Set-Cookie는 문서화된 예외입니다: Expires 날짜에 쉼표가 있어 쉼표 병합이 불가능하므로, 프록시는 각 Set-Cookie를 따로 전달해야 합니다. 이 예외가 프록시 버그의 고전적인 원인입니다.

필드 이름이 소문자가 되었고 HPACK 또는 QPACK으로 압축된 바이너리 프레임으로 이동합니다; 각 요청은 자체 스트림을 열고, Host 같은 연결별 헤더는 :method, :scheme, :path와 함께 :authority 유사 헤더로 대체되었습니다. 의미론적으로 필드는 여전히 RFC 9110을 따릅니다 - 바뀐 것은 전송 형식이지 어휘가 아닙니다.

필드 이름과 콜론 사이의 공백(Header : value) - HTTP/1.1 파싱과 HTTP/2 명세 모두 요청 밀반입을 막기 위해 이를 거부합니다. 또한 잘못된 것: 필드 이름 안의 공백이나 비-ASCII 바이트, 값의 제어 문자, 그리고 obs-fold(들여쓰기 줄로 이어지는 헤더)로, RFC 9110은 이를 폐기 표시했습니다 - 한 줄 또는 목록 값으로 바꾸세요.