네트워크/HTTP
HTTP Headers Parser
원시 HTTP 헤더(curl -I, DevTools, raw response 등)를 설명이 포함된 필드 목록으로 분해하고 보안 헤더를 확인합니다.
Raw HTTP headers from curl -I or the Network tab in DevTools look like one solid block of text. This tool breaks it down into individual fields, explains what each header does, and flags common missing security headers.
How to use it
- Paste raw headers (curl -I output, the Headers tab in DevTools, or a copied raw response).
- Each header is parsed out individually with a short explanation of what it means.
- Missing security headers (Content-Security-Policy, X-Content-Type-Options, etc.) are flagged with a warning.
Common uses
- Quickly checking a site's security headers before a release or an audit.
- Understanding an unfamiliar header from a third-party API response without looking it up every time.
- Debugging caching or CORS issues by analyzing the server's response headers.
Things to keep in mind
Header order mostly doesn't matter for HTTP, except in rare cases involving repeated headers of the same type (e.g. multiple Set-Cookie headers).
A missing security header isn't always a mistake — some of them (HSTS, for example) only make sense for HTTPS sites or specific use cases.
자주 묻는 질문
요청 헤더와 응답 헤더의 차이는 무엇인가요?
요청 헤더는 클라이언트가 무엇을 요청하는지 설명하기 위해 보내고(Accept나 Authorization 등), 응답 헤더는 서버가 무엇을 반환하는지 설명하기 위해 보냅니다(Content-Type이나 Cache-Control 등).
일부 헤더 이름이 다른 대소문자로 표시되는 이유는 무엇인가요?
HTTP 헤더 이름은 사양상 대소문자를 구분하지 않으므로 Content-Type과 content-type은 동일합니다 — 서버와 도구마다 표시 방식에 대한 관례가 다를 뿐입니다.
여기서 헤더를 파싱하면 어딘가로 전송되나요?
아니요. 모든 파싱은 브라우저 내에서 완전히 이루어집니다 — 서버에 업로드되는 것은 없습니다.
같은 응답에 여러 개의 Set-Cookie 헤더가 나올 수 있는 이유는 무엇인가요?
HTTP는 의미가 있을 때 같은 헤더를 반복하는 것을 허용합니다 — Set-Cookie가 가장 흔한 예로, 설정되는 쿠키마다 각자의 줄과 속성이 필요하기 때문입니다.
헤더의 순서가 중요한가요?
같은 헤더가 여러 번 나타나는 경우를 제외하면 거의 중요하지 않습니다 — 그런 경우에는 반복되는 인스턴스 사이의 순서가 의미를 가질 수 있습니다(여러 Set-Cookie 헤더의 경우처럼).