요청 본문에 제목을 보냈는데 서버가 “제목을 입력해주세요”라고 답한다면 필드 이름뿐 아니라 본문 형식도 확인해야 합니다. win-j의 관리자 글 저장 코드는 폼 값을 읽습니다. JSON 데이터를 전송하고 JSON 응답을 받는다는 두 문장은 서로 다른 방향의 계약입니다.

Content-Type과 Accept의 방향

헤더 누가 무엇을 설명하는가 예
요청 Content-Type 클라이언트가 보내는 본문의 형식 폼 또는 JSON
응답 Content-Type 서버가 반환한 본문의 형식 HTML 또는 JSON
요청 Accept 클라이언트가 받을 수 있는 형식 application/json
응답 Location 이동 또는 생성된 대상의 주소 /utility/
요청 Cookie / 응답 Set-Cookie 저장된 쿠키 전달 / 쿠키 설정 세션 식별자 등

Accept: application/json을 보낸다고 로그인 HTML이 자동으로 JSON으로 변하지 않습니다. 서버가 어떤 형식을 지원하고 오류를 어떻게 반환하는지 확인해야 합니다. 헤더 이름은 대소문자를 구분하지 않지만, 필드별 값의 규칙은 다릅니다. HTTP 헤더 안내

네트워크 요청 없이 전송 형식 비교하기

아래 Python 코드는 요청을 준비만 하므로 서버의 글을 만들거나 변경하지 않습니다. 주소는 예시용 예약 도메인입니다.

from requests import Request

url = "https://example.com/posts"
payload = {"title": "hello"}
form_request = Request("POST", url, data=payload).prepare()
json_request = Request("POST", url, json=payload).prepare()
print(form_request.headers["Content-Type"])
print(form_request.body)
print(json_request.headers["Content-Type"])
print(json_request.body.decode("utf-8"))

폼은 application/x-www-form-urlencoded와 title=hello, JSON은 application/json과 {"title": "hello"}를 출력합니다. 같은 Python 사전에서 시작했지만 HTTP 본문은 다릅니다. Requests의 요청 본문 옵션

현재 /manager/posts/write-v2/는 request.POST에서 필드를 읽습니다. staff 로그인 상태여도 JSON 본문으로 보내면 폼 필드를 찾지 못할 수 있습니다. 실제 브라우저 저장 요청에는 세션과 CSRF 조건도 추가되므로 형식만 맞췄다고 저장 권한이 생기는 것은 아닙니다.

개발자 도구에서 비교할 순서

  1. Network에서 문제가 발생한 요청을 선택합니다.
  2. Request Headers의 Content-Type과 Payload의 실제 모양을 비교합니다.
  3. 상태와 Response Headers의 Content-Type을 확인합니다.
  4. Response의 오류 메시지를 읽되 쿠키·토큰·개인정보는 공유 전에 지웁니다.

GET 조회에는 본문이 없는 경우가 많아 요청 Content-Type을 임의로 추가할 필요가 없습니다. 오히려 교차 출처 요청에 불필요한 JSON Content-Type이나 사용자 정의 헤더를 추가하면 preflight가 생길 수 있습니다. CORS 점검 순서

캐시 문제를 볼 때 no-cache와 no-store 구분

no-cache는 저장 금지가 아니라 저장된 응답을 재사용하기 전에 서버에 검증하라는 지시입니다. no-store는 응답 저장을 하지 말라는 지시이며, private은 공유 캐시의 저장을 제한합니다. ETag와 조건부 요청이 맞으면 서버가 본문 대신 304를 반환할 수 있습니다. Cache-Control 정의

페이지 수정이 보이지 않을 때는 응답의 Cache-Control·ETag·Age와 브라우저의 캐시 사용 표시를 확인합니다. 이후 CDN·프록시·애플리케이션 중 어느 계층의 응답인지 좁힙니다. 모든 응답에 무조건 no-store를 붙이는 것은 정적 파일 캐시까지 없애 성능을 해칠 수 있습니다.

이 사이트 헤더 분석기의 실제 범위

현재 헤더 분석기는 사용자가 붙여넣은 헤더 텍스트를 JavaScript로 파싱합니다. URL을 입력하면 원격 서버에 접속해 최신 헤더를 수집하는 도구가 아닙니다. 개발자 도구나 HTTP 클라이언트에서 얻은 텍스트를 먼저 준비해야 합니다.

분석 결과에 CSP·HSTS 항목이 보이거나 높은 점수가 나와도 사이트 전체의 보안을 증명하지는 않습니다. 정책의 값, 실제 요청 경로, 프록시의 헤더 변경까지 확인해야 합니다. 특히 여러 응답의 헤더를 한꺼번에 붙이면 어느 단계의 값인지 혼동하기 쉬우므로 최종 응답 하나씩 비교합니다.

Set-Cookie는 응답에 여러 번 나올 수 있습니다. 이를 임의로 쉼표 하나로 합치면 만료일과 개별 쿠키의 경계를 잘못 해석할 수 있습니다. 원문을 보존하고 헤더별 문법을 아는 도구로 확인합니다. Set-Cookie 헤더

헤더를 확인했다면 상태코드와 이동 이력, 쿠키·세션의 저장 위치를 함께 대조하면 요청 실패의 원인을 더 좁힐 수 있습니다.