HTTP 요청이나 응답 전체를 붙여넣으세요 — curl -v가 인쇄하는 블록이나 브라우저 네트워크 패널이 보여주는 것 — 그러면 모든 헤더 줄이 해석됩니다: 이름, 값, 그것이 하는 일에 대한 쉬운 설명, 그것을 정의하는 문서. Set-Cookie는 속성별로 분해되고(Secure, HttpOnly, SameSite, Max-Age, Expires…), Content-Type과 Accept 매개변수는 확장되며, 블록은 고전적 구조 문제에 대해 감사됩니다: 낡은 접힌 줄, 허용되지 않는 문자, 중복 헤더, 잘못된 방향의 헤더. 모든 것이 브라우저에서 돌고 아무것도 업로드되지 않습니다.
입력
자동은 첫 줄을 봅니다: 요청 줄(GET /path HTTP/1.1)이면 요청, 상태 줄(HTTP/1.1 200 OK)이면 응답, 그 외는 순수한 헤더 블록으로 읽습니다. 다른 선택은 방향을 강제하며 어떤 경고가 적용되는지를 바꿉니다.
파싱 보고서 (0)
아직 파싱된 것이 없습니다. 위에 요청 또는 응답 블록을 붙여넣고 헤더 파싱을 누르거나, 실행 예제를 보려면 샘플을 누르세요.
파싱할 만한 블록을 어디서 얻나요. 터미널에서 curl -v https://example.com/ 2>&1은 요청과 응답을 >와 < 접두사와 함께 인쇄합니다 — 그것을 벗기고 붙여넣으세요. curl -sI https://example.com/은 응답 헤더 블록만 줍니다. 브라우저에서는 개발자 도구, 네트워크 탭을 열고 다시 로드해 문서 요청을 선택한 뒤 복사 → 응답 헤더 복사를 쓰세요. 요청 쪽은 cURL로 복사를 쓰고 플래그를 읽으세요. 시작 줄 없는 Name: value 줄의 평범한 블록도 파싱됩니다 — 방향 검사는 완화됩니다.
자체 테스트 파서를 고정 블록에 대해 재구동합니다: 방향 감지, 두 샘플 풀, 모든 Set-Cookie 속성 규칙(Secure 없는 SameSite=None, 숫자 아닌 Max-Age, 깨진 Expires, 알 수 없는 속성, = 없는 쿠키), obs-fold 결합, 잘못된 필드 이름, 중복 헤더, 방향 불일치, 부정 경로. 아무것도 전송되지 않습니다.
HTTP 헤더란?
한 문장으로: HTTP 메시지는 시작 줄, 헤더라 불리는 Name: value 줄의 블록, 빈 줄, 선택적 본문입니다 — 헤더는 본문 자체를 제외한 메시지에 관한 모든 것을 실습니다: 누가 보냈는지, 무엇을 받아들이는지, 어떻게 캐시되는지, 어떻게 인증되는지, 송신자가 무엇을 원하는지.
일부 헤더는 확실히 단방향입니다. If-None-Match는 요청에서만, Set-Cookie는 응답에서만 의미가 있습니다. 잘못된 방향으로 파싱하는 것은 고전적인 복붙 디버깅 실수 중 하나라 이 페이지가 깃발을 답니다.
헤더 줄의 문법
RFC 9110은 필드 줄을 field-name ":" OWS field-value OWS로 정의합니다 — 토큰 문자(글자, 숫자, !#$%&'*+-.^_`|~)만으로 된 이름, 앞에 공백 없는 콜론, 보이는 문자와 스페이스·탭의 값. 헤더 이름은 대소문자를 무시합니다(content-type은 Content-Type과 같음). 값은 거의 항상 대소문자를 구분합니다. 스페이스나 탭으로 시작하는 줄은 예전에 이전 헤더를 계속하는 것이었습니다 — obs-fold, 2014년부터 폐기. 그것을 펼치는 프록시는 헤더의 의미를 바꿀 수 있어 여기의 파서는 결합하되 경고합니다.
흔한 실수
X-Forwarded-For를 믿기. 경로의 모든 프록시가 추가하며 클라이언트는 첫 홉을 위조할 수 있습니다. 프록시 사슬의 주장이지 연결된 사람이 아닙니다. 힌트로 대하고 통제하는 프록시가 덮어쓰게 하세요.
응답 헤더만 읽기. 흥미로운 실수의 절반(중복된 Accept, 빠진 Host, 잘못된 호스트를 겨냥한 인증 헤더)은 브라우저가 기본으로 숨기는 요청에 있습니다. cURL로 복사로 자신의 것을 보세요.
Set-Cookie 줄 병합. 중복된 대부분의 헤더는 쉼표로 합쳐질 수 있습니다 — Set-Cookie는 안 됩니다. 쉼표가 값 자체 안에 나타나기 때문입니다. 브라우저는 각 줄을 별도 쿠키로 취급합니다.
Content-Length가 쓴 본문 크기일 것이라 기대하기.Content-Encoding이 적용된 후의 크기이며 메시지가 청크되지 않았을 때만입니다. Transfer-Encoding: chunked 응답에는 의미 있는 단일 길이가 없습니다.
X- 접두사로 헤더 판단하기. 그 관례는 RFC 6648에서 죽었습니다. X-Forwarded-For와 X-Content-Type-Options는 영구적 사실상 표준이고 X 없는 헤더도 실험적인 것이 많습니다. 접두사가 아니라 정의 문서로 판단하세요.
FAQ
여기 헤더를 붙여넣어도 안전한가요? 파싱은 완전히 브라우저에서 이루어지고 아무것도 업로드되지 않습니다. 그래도 복사된 헤더 블록은 지문입니다. 쿠키, 인증 헤더, 정확한 User-Agent가 함께면 당신을 식별할 수 있으니 동료에게 보여도 괜찮은 블록을 파싱하세요.
브라우저가 :status 같은 헤더를 보여주는데 이 페이지는 오라 하는 이유는? HTTP/2와 HTTP/3 유사 헤더입니다 — 바이너리 프레이밍 계층이 시작 줄과 Host를 유사 필드로 대체합니다. 이 페이지는 고전적 HTTP/1.1 전선 텍스트를 파싱합니다. 유사 헤더는 프로토콜이 번역한 같은 정보입니다.
X-XSS-Protection은 어찌 되었나요? 폐기되었습니다. 그것이 구동하던 감사기가 자체 보안 버그를 일으켜 브라우저가 제거했습니다. 그 임무는 Content-Security-Policy의 것입니다 — CSP 생성기에서 만들고 보안 헤더 검사기에서 전체를 감사하세요.
Set-Cookie 속성은 어떻게 검사되나요? RFC 6265에 따라: 이름과 값은 첫 =에서 나뉘고 속성은 첫 세미콜론 뒤에, Expires는 쿠키 형식의 날짜여야 하고 Max-Age는 숫자, SameSite는 Strict/Lax/None 중 하나 — Secure 없는 None은 최신 브라우저가 거부하므로 지적됩니다.
헤더 줄 목록만 파싱할 수 있나요? 네 — 헤더 블록만을 고르고 시작 줄 없이 붙여넣으세요. 방향 검사는 완화되고 나머지(구조, Set-Cookie, 매개변수)는 여전히 돕습니다.
