과거 한국 웹사이트 상당수가 EUC-KR 인코딩으로 작성되어 있었기 때문에, 지금도 오래된 레거시 시스템의 응답에서 Content-Type: text/html; charset=EUC-KR처럼 UTF-8이 아닌 값을 만나는 경우가 있다. 이 헤더의 charset과 HTML 문서 안의 <meta charset> 태그가 서로 다르면 브라우저가 인코딩을 잘못 추측해 한글이 깨져 보이는 전형적인 원인이 된다.
요청 헤더와 응답 헤더의 차이
브라우저는 요청 헤더(Accept, User-Agent, Cookie 등)를 서버로 보내 자신과 기대 사항을 설명한다. 서버는 그에 대한 응답으로 응답 헤더(Content-Type, Set-Cookie, Cache-Control 등)를 보내 반환되는 데이터와 브라우저에 대한 지침을 설명한다.
Content-Type이 필요한 이유
Content-Type 헤더는 응답 본문을 HTML 페이지, JSON 데이터, 이미지, 다운로드 파일 중 무엇으로 해석해야 하는지 브라우저에 알려준다. 여기에 올바른 값이 없으면 브라우저가 JSON을 일반 텍스트로 표시하려 하거나, 반대로 HTML을 잘못 처리할 수 있다.
Cache-Control이 캐싱을 제어하는 방식
max-age=3600이나 no-cache 같은 값은 서버에 새 요청을 보내지 않고도 리소스의 캐시된 사본을 얼마나 오래 사용할 수 있는지 브라우저와 중간 서버에 알려준다. 이 헤더를 잘못 설정하는 것은 사용자가 사이트의 오래된 버전을 보게 되는 흔한 원인이다.
왜 필요한가
- 브라우저가 API 응답을 잘못 표시하는 이유를 진단한다.
Content-Type의charset값과 HTML 안의<meta>태그 인코딩이 서로 일치하는지 확인한다.- 사이트가 HTTPS로 제공되는지 확인한다 — 이 사이트 자체의 해시 및 JWT 도구가 의존하는 Web Crypto API가 동작하기 위한 필수 조건이다.
같은 헤더가 여러 번 나오는 이유
HTTP는 같은 헤더가 하나의 응답에서 여러 번 나타나는 것을 허용한다 — 가장 흔한 예는 설정되는 쿠키마다 하나씩 붙는 여러 개의 Set-Cookie 줄이다. 대부분의 다른 반복 헤더는 의미를 바꾸지 않고 쉼표로 구분된 하나의 값으로 합칠 수 있지만, Set-Cookie는 의도적인 예외다. 쉼표가 쿠키 값의 정당한 일부일 수 있기 때문이다.