응답 본문을 헤더로 붙여 넣기
빈 줄은 HTTP 헤더 구간을 끝냅니다. 다음 비어 있지 않은 줄이 유효한 요청·응답 시작 줄이 아니면 이후 본문은 개수만 알리고 무시합니다.
요청·응답 디버깅용 HTTP 헤더 파서
인코딩브라우저에서 실행(업로드 없음)
HTTP 요청 또는 응답 헤더 블록을 브라우저에서 제한된 범위로 분석합니다. 리디렉션 구간을 분리하고 필드 이름과 중복을 검사하며, 민감한 값은 기본으로 가리고 잘못된 줄과 위험도 높은 프레이밍 조합을 알립니다. URL을 직접 요청하지 않습니다.
다음에 할 작업
관련 작업 흐름을 이어가거나 이 작업 다음에 자주 사용하는 도구를 열어보세요.
작업 가이드
배포 전에 Content-Security-Policy 헤더 분석하기
CSP가 필요한 리소스를 차단하거나 후보 정책이 과도한 보고서를 만들거나 프록시가 의도한 헤더를 바꿀 때 사용하는 절차입니다. 로컬 정책 파싱, 브라우저 위반 증거, 마지막 배포 엣지 재확인을 결합하며 정적 결과를 보안 인증으로 취급하지 않습니다.
열기관련 도구Base64 인코더와 디코더 | UTF-8·Base64URL·Data URI
UTF-8을 엄격하게 인코딩하고 Base64·Base64URL·Data URI·바이너리 바이트를 로컬에서 디코딩합니다.
열기관련 도구CSP 헤더 분석기 | Content Security Policy 검토
CSP 정책, 첫 유효 directive, source expression과 시행 문맥을 로컬에서 검토합니다.
열기관련 도구개발자 변환 워크벤치 | 쿼리·CSS·이스케이프·진법·커밋 도구
진법, 쿼리, px/rem, 문자열 이스케이프, 커밋 메시지를 하나의 로컬 워크벤치에서 처리합니다.
열기이 도구 사용 방법
가능하면 시작 줄과 빈 줄 경계를 포함해 실제 요청 또는 응답의 헤더 블록을 캡처합니다.
브라우저에서 로컬 처리되더라도 재사용할 예제에서는 운영 비밀과 고객 개인정보를 먼저 제거합니다.
리포트를 복사·다운로드·공유할 가능성이 있으면 민감한 헤더 값 마스킹을 켠 상태로 둡니다.
각 리디렉션 또는 프록시 블록의 줄 범위, 시작 줄, 그룹, 중복 개수를 따로 확인합니다.
잘못된 줄 경고를 해결하고 Content-Length 충돌, Transfer-Encoding과 Content-Length 동시 존재, 중복 Host 신호를 실제 네트워크 구간에서 조사합니다.
리포트를 실제 브라우저 또는 서버 트랜잭션과 비교합니다. 이 도구는 URL 요청, 요청 재현, 정책 의미 검증 또는 보안 판정을 수행하지 않습니다.
이 도구를 써야 할 때
리디렉션·프록시 체인 확인
301, 302, 인증, 프록시 터널, 최종 응답 헤더를 한 응답의 중복으로 합치지 않고 구간별로 분리합니다.
프레이밍·중복 필드 점검
블록별 반복 필드와 Content-Length 충돌, Transfer-Encoding과 Content-Length 동시 존재, 중복 Host 조합을 찾아 수동 조사합니다.
캐시·CORS·콘텐츠 그룹 분류
캐시, CORS, 콘텐츠 협상, 요청, 응답, 쿠키, 인증, 보안, 사용자 정의 필드 이름을 값의 적합성 판정 없이 빠르게 찾습니다.
공유 가능한 디버깅 자료
자격 증명, 쿠키, API 키, 클라이언트 주소, WebSocket 키 같은 값을 기본으로 가린 정규화 리포트를 만듭니다.
흔한 실수
모든 반복 필드를 오류로 보기
Set-Cookie와 인증 challenge는 의도적으로 반복될 수 있습니다. 필드의 프로토콜 의미와 발생 블록을 함께 확인하세요.
마스킹을 끈 리포트를 공유하기
로컬 분석은 업로드를 막지만 클립보드, 다운로드, 화면 캡처, 이슈, 채팅에 들어간 값은 별도로 노출될 수 있습니다.
접힌 줄을 현대 HTTP 문법으로 인정하기
구식 folded value는 조사 편의를 위해 이전 값에 합치되 항상 경고합니다. 새 요청이나 응답에서 다시 생성하면 안 됩니다.
파서 신호를 보안 판정으로 확정하기
의심스러운 프레이밍 조합은 구간별 원시 메시지 분석이 필요합니다. 모든 프록시, HTTP 버전 변환, 캐시, CORS, CSP, 쿠키 규칙을 이 도구가 모델링하지는 않습니다.
예시
리디렉션과 최종 응답 분리
두 응답 블록을 분리하고 기본 내보내기에서는 Set-Cookie 값을 가립니다.
입력
HTTP/1.1 302 Found
location: https://api.example.com/v2
set-cookie: session=private; Path=/; Secure; HttpOnly
HTTP/2 200
content-type: application/json
cache-control: no-store출력
HTTP/1.1 302 Found
location: https://api.example.com/v2
set-cookie: [REDACTED]
HTTP/2 200
content-type: application/json
cache-control: no-store자격 증명과 반복 Accept가 있는 요청 확인
메서드 대소문자를 유지하고 Authorization 값은 가리며, 두 Accept 필드는 중복 검토를 위해 모두 남깁니다.
입력
GET /v1/users?page=2 HTTP/1.1
Host: api.example.com
Authorization: Bearer private-token
Accept: application/json
Accept: text/plain출력
GET /v1/users?page=2 HTTP/1.1
host: api.example.com
authorization: [REDACTED]
accept: application/json
accept: text/plain분석 경계와 프로토콜 신호
입력 한도는 UTF-8 500,000바이트, 10,000줄, 줄당 32,768바이트, 허용된 필드 2,000개, 헤더 블록 20개입니다. 큰 결과 구조를 만들기 전에 한도를 검사합니다.
요청 메서드는 HTTP token 문법으로 검사하고 원래 대소문자를 유지합니다. 일반 필드 이름은 token 문법을 따르며, 소문자 HTTP/2 의사 헤더는 일반 필드보다 앞에 있을 때만 경고 없이 허용합니다.
빈 줄이 블록을 닫습니다. 다음 유효한 요청·응답 시작 줄은 새 블록을 열고, 그렇지 않으면 남은 비어 있지 않은 줄을 본문 또는 후행 데이터로 보고 개수와 함께 무시합니다.
구식 folded line은 조사 편의를 위해 앞 값에 합치고 경고합니다. 유효하지 않은 이름, 빈 이름, 금지 제어문자, 앞 필드가 없는 들여쓰기, 구분자가 없는 줄은 정상 필드처럼 보이게 고치지 않고 건너뜁니다.
반복 필드는 블록별로 보존합니다. 잘못되거나 충돌하는 Content-Length, Transfer-Encoding과 Content-Length 동시 존재, 중복 Host를 표시하지만 실제 영향은 원시 바이트와 모든 중간 시스템을 확인해야 판단할 수 있습니다.
자주 묻는 질문
헤더를 서버로 보내거나 URL을 직접 요청하나요?
아니요. 분석은 이 브라우저에서 실행되고 붙여 넣은 호스트로 요청하지 않습니다. 분석 이벤트에도 붙여 넣은 헤더 값을 포함하면 안 됩니다.
기본으로 어떤 값을 가리나요?
Authorization, 프록시 인증, 쿠키, API 키, CSRF 토큰, 전달된 클라이언트 주소, WebSocket 키 같은 일반적인 민감 필드를 리포트에서 가립니다. 그 밖의 사설 이름, URL, 식별자, 공급자 전용 자격 증명은 공유 전에 직접 제거하세요.
응답 블록이 여러 개 표시되는 이유는 무엇인가요?
리디렉션, 프록시 터널, 반복 캡처에는 빈 줄로 구분된 시작 줄이 여러 개 있을 수 있습니다. 서로 다른 구간의 필드를 한 응답의 중복으로 처리하면 안 됩니다.
Set-Cookie가 반복되면 충돌인가요?
그 자체로는 아닙니다. Set-Cookie는 보통 별도 필드 줄을 사용합니다. 리포트는 예상 가능한 반복, singleton 충돌, 추가 검토가 필요한 중복을 구분합니다.
Transfer-Encoding과 Content-Length가 함께 있으면 요청 스머글링이 확정되나요?
아니요. 우선 조사해야 할 신호입니다. 영향은 HTTP 버전, 원시 메시지, 파싱 차이, 정규화 방식, 경로의 각 프록시와 서버에 따라 달라집니다.
CORS·캐시·쿠키·보안 헤더 테스트를 대신할 수 있나요?
아니요. 그룹 분류는 관련 필드 이름을 찾을 뿐입니다. 실제 요청 조건, 브라우저 진단, 정책별 도구, 최종 동작으로 의미를 검증해야 합니다.
이 도구를 검증한 방법
관리 및 검수 SimpleWebUtils검토일
검증 방법: 가이드 입력을 바꾸지 않은 채 요청·응답 디버깅용 HTTP 헤더 파서에서 다음 예제를 재현했습니다: “리디렉션 뒤 최종 API 응답이 이어지는 사례”. 정상 절차는 “원본에서 비밀값 제거”, “위험한 framing 신호 조사”; 경계 검토는 “모든 리디렉션을 한 응답으로 합침”, “framing 경고를 확정된 공격으로 단정”로 분리해 결과를 확정했습니다.
기대 결과: 파서는 302와 200 응답을 두 block으로 유지하고 민감 값 3개를 마스킹했으며, 반복 Set-Cookie를 보존하고 충돌하는 framing header를 표시했습니다.
공식 출처와 표준
- RFC 9110: HTTP SemanticsRFC Editor / IETF
관련 작업 가이드
도구를 열기 전에 자주 쓰는 작업 흐름과 예시를 확인하세요.
작업 가이드
배포 전에 Content-Security-Policy 헤더 분석하기
CSP가 필요한 리소스를 차단하거나 후보 정책이 과도한 보고서를 만들거나 프록시가 의도한 헤더를 바꿀 때 사용하는 절차입니다. 로컬 정책 파싱, 브라우저 위반 증거, 마지막 배포 엣지 재확인을 결합하며 정적 결과를 보안 인증으로 취급하지 않습니다.
작업 가이드시간대와 DST를 가로질러 Cron 일정 검증하기
Cron 표현식은 필드 방언, IANA 시간대, 기준 instant, DST 동작과 누락 실행 정책이 정해져야 완전한 일정이 됩니다. 이 절차는 모든 기준 날짜를 명시적인 ISO 8601 instant로 바꾸고 5필드 Unix cron을 필드별로 검사합니다. 이어 로컬 벽시계와 UTC의 다음 실행을 비교하고 일광 절약 시간 전환을 시험한 뒤, 실제 운영 스케줄러에서 같은 fixture를 검증합니다.
작업 가이드인코딩된 쿼리 매개변수를 이중 디코딩 없이 디버깅하는 방법
콜백, 검색 링크, 웹훅, API 요청이 여러 파서를 거치면서 더하기 기호, 반복 키, JSON 문자열 이스케이프, 중첩 반환 URL을 바꿀 때 사용하는 절차입니다.
작업 가이드HTTP 응답 헤더 확인하기
브라우저 요청, API 응답, 리디렉션, CDN 캐시가 예상과 다를 때 설정을 먼저 바꾸지 않고 제한이 명확한 비식별 헤더 기록부터 만드는 흐름입니다.
작업 가이드API 디버깅을 위해 JSON 원문을 보존해 정리하기
압축된 응답을 읽기 어렵거나 fixture의 엄격한 파싱이 실패할 때, 일반적인 클라이언트 오류를 정확한 JSON 위치까지 추적하면서 구문 유효성과 API 계약 유효성을 혼동하지 않는 워크플로입니다.
작업 가이드JSONPath로 큰 API 응답 디버깅하기
버그 리포트, 테스트 실패, 운영 로그에 큰 JSON payload가 포함됐지만 실제로 비교해야 할 값은 몇 개뿐일 때 사용하는 작업 흐름입니다.
작업 가이드출시 전 마지막 응답 보안 헤더 점검하기
curl -I 또는 DevTools 캡처를 반복 가능한 출시 증거로 바꾸는 절차입니다. 마지막 응답을 로컬에서 검사하고 시행 CSP와 Report-Only 관찰을 구분하며, 배포 문맥을 기록한 뒤 헤더만으로 확인할 수 없는 애플리케이션 테스트까지 이어갑니다.
작업 가이드API 로그에서 타임스탬프 추출하고 변환하기
필드명과 원본 줄, 정확한 epoch 정밀도, 명시적인 단위 판단을 유지하면서 작고 비식별화된 로그나 payload를 검토 가능한 타임스탬프 행으로 바꾸는 방법입니다.
작업 가이드Unix 타임스탬프로 UTC 장애 타임라인 만들기
타임스탬프 필드를 식별한 뒤 여러 시스템의 사건을 정렬하고, 사건 시각과 수집 시각을 구분하며, clock skew를 기록하고, 인과관계를 과장하지 않고 결과를 설명하는 절차입니다.
작업 가이드JWT 만료와 not-before 타임스탬프 확인하기
요청이 nbf 전인지, exp와 같거나 이후인지, 선언된 token 구간 안인지 판단하면서 clock skew 정책을 기록하고 공유 증거에서는 원본 token을 제거하는 절차입니다.
작업 가이드이중 인코딩된 쿼리 값 하나를 계층별로 복구하기
callback, webhook, proxy, SDK, 복사한 링크에 `%252F`, `%2520`, `%253A`처럼 퍼센트 기호가 다시 인코딩된 흔적이 있을 때 사용하는 절차입니다.
작업 가이드Query 순서와 encoding 증거를 잃지 않고 callback URL 디버깅하기
OAuth, SSO, webhook, campaign, application callback이 브라우저에서는 정상처럼 보이지만 수신 system이 다른 path나 parameter 값을 읽을 때 사용하는 절차입니다.
관련 도구
관리 중인 다른 작업 흐름을 이어서 사용해 보세요
Base64 인코더와 디코더 | UTF-8·Base64URL·Data URI
UTF-8을 엄격하게 인코딩하고 Base64·Base64URL·Data URI·바이너리 바이트를 로컬에서 디코딩합니다.
인코딩
CSP 헤더 분석기 | Content Security Policy 검토
CSP 정책, 첫 유효 directive, source expression과 시행 문맥을 로컬에서 검토합니다.
보안
개발자 변환 워크벤치 | 쿼리·CSS·이스케이프·진법·커밋 도구
진법, 쿼리, px/rem, 문자열 이스케이프, 커밋 메시지를 하나의 로컬 워크벤치에서 처리합니다.
변환
JWT 디코더: 클레임과 만료 시간 확인
서명을 검증하지 않고 JWT 구조와 시간 클레임을 엄격하게 로컬 디코딩합니다.
보안
보안 헤더 확인기 | 마지막 응답 점검
붙여넣은 마지막 HTTP 응답에서 시행 여부와 문맥을 반영한 보안 헤더 신호를 검토합니다.
보안
URL 파서 및 분석기 | Query Parameter와 상대 URL
절대 URL 또는 상대 참조를 파싱해 raw, decoded, 정규화, 중복 query 보기를 제공합니다.
변환