304 응답의 본문이 0바이트인 이유를 직접 확인했다

내 ETag로 조건부 요청 비교하기

ETag를 바꾸며 어떤 조건이 일치하는지 확인합니다. 선택된 현재 표현이 존재하고, 다른 조건에서는 정상 200이 되는 GET/HEAD 요청을 가정합니다. 입력 문자열을 비교하는 연습이며 서버에 HTTP 요청을 보내거나 실제 캐시 적중을 검사하지 않습니다.

서버의 현재 ETag 값 요청의 If-None-Match 값

기본 예시 · "v1"과 W/"v1"은 약한 비교에서 일치합니다. 위 정상 응답 가정에서 GET/HEAD는 304 경로입니다.

세 입력을 바꿔 보세요

1. 요청을 "v2" 하나로 바꾸면 현재 "v1"과 불일치합니다.
2. 현재 태그를 W/"v1", 요청을 "v1"로 바꿔도 약한 비교는 일치합니다.
3. "a,b"는 쉼표가 포함된 태그 하나입니다. 목록을 단순히 쉼표로 쪼개면 잘못 셉니다. *는 현재 표현이 있다는 이 연습의 가정에서 일치합니다.

RFC 9110 §13.1.2의 If-None-Match는 약한 비교를 사용합니다. 이 연습은 PUT·삭제 요청, 인증 실패, 다른 선행 조건, 캐시 보관 정책을 판정하지 않습니다. 약한 일치가 두 본문의 바이트가 완전히 같다는 뜻도 아닙니다.

태그만 입력하면 됩니다. 입력은 브라우저 메모리에서 처리하며 저장·전송하지 않습니다. 실제 Nginx 응답은 이 글의 별도 격리 실험과 원자료에서 확인할 수 있습니다.

네트워크 도구에 304가 표시되고 응답 본문이 비어 있으면 파일 전송이 실패한 것처럼 보일 수 있다. 이번 실험은 같은 정적 파일을 두 번 요청하되, 두 번째 요청에만 첫 응답의 ETag를 넣었다. 다른 캐시 계층이나 브라우저 저장소를 끼우지 않고 HTTP 응답만 비교했다.

파일은 그대로 두고 요청 헤더만 바꿨다

sample.txt에는 짧은 테스트 문자열을 저장했다. 첫 요청에서 받은 본문 크기와 ETag를 기록한 다음, If-None-Match에 그 ETag를 그대로 넣어 다시 요청했다. 실험 도중 파일 내용이나 수정 시각은 바꾸지 않았다.

GET /sample.txt

# 첫 응답에서 받은 ETag 값을 그대로 사용
GET /sample.txt
If-None-Match: "FIRST_RESPONSE_ETAG"

0바이트는 파일이 사라졌다는 뜻이 아니었다

첫 응답은 파일 본문을 포함했고 두 번째 응답은 본문 없이 304로 끝났다. 요청자가 기존 표현을 가지고 있다는 조건을 헤더로 전달했기 때문이다. 이 결과를 처음 방문한 사용자에게 아무 파일도 보내지 않는 동작과 혼동하면 안 된다. 실험에서 처음 요청한 경우에는 200과 본문을 받았다.

응답 본문 크기 0과 통신량 0도 다르다. 두 번째 요청과 응답 헤더의 왕복은 남아 있다. 여기서 기록한 bytes는 본문 길이이며 패킷 전체 크기나 사용자의 체감 로딩 시간은 측정하지 않았다.

갱신이 안 보일 때 확인할 순서

무조건 캐시를 끄기 전에 파일이 배포된 위치와 실제 응답을 비교한다. 로컬 파일만 바꾸고 웹 서버가 다른 디렉터리를 보고 있으면 새로고침으로 해결되지 않는다. 반대로 정상적인 304를 오류로 집계하면 캐시가 잘 동작할수록 실패 수가 늘어나는 잘못된 대시보드가 만들어질 수 있다.

표는 원인을 확정하는 규칙이 아니라 다음 확인 지점을 좁히는 순서다. 아래 후속 실험은 첫 번째 경우를 의도적으로 만들었다. 운영에서 조건 없는 요청을 보낸다고 CDN의 저장본까지 반드시 우회하는 것은 아니다.

• 원본이 503이어도 화면은 200: 오래된 캐시를 구분하는 법

  응답 본문 자체가 이전 값이면 저장본을 반환하는 계층도 확인한다.

이번 기록을 적용할 범위

작은 정적 파일을 대상으로 검증 요청을 이해하는 데 사용할 수 있다. 브라우저의 강제 새로고침 동작이나 CDN의 캐시 정책은 따로 확인해야 한다. 이 글은 ETag를 보안 해시로 검증하거나 파일의 모든 변경을 감지하는 방식을 시험한 기록은 아니다.

추가 확인: ETag가 내용 전체의 해시라고 가정하면 안 된다

304 응답을 이해할 때는 서버가 ETag를 어떤 정보로 만드는지도 중요하다. 추가 실험에서는 정적 파일을 version-a에서 version-b로 바꿨다. 두 문자열은 모두 9바이트다. 파일 크기를 같게 유지하고 수정 시각(mtime)도 같은 값으로 되돌린 뒤, 최초 응답의 ETag를 If-None-Match로 보냈다.

내용이 바뀌었는데도 이 조건부 요청은 304와 빈 본문을 반환했다. 같은 파일을 조건 헤더 없이 요청하면 200과 version-b가 나왔다. 이어 mtime을 2초 뒤로 바꾸고 최초 ETag로 요청하자 200과 새 본문을 받았다. 응답을 바꾼 조건이 무엇인지 파일 내용, 크기, 시각을 분리해 관찰한 것이다.

이번 결과가 의미하는 배포상의 주의점

여기서 시험한 Nginx 1.18.0의 정적 파일 응답에서는 파일 내용이 다르다는 사실만으로 ETag가 달라지지 않았다. 모든 서버나 애플리케이션의 ETag가 같게 동작한다는 뜻은 아니다. 이 결과만으로 브라우저 화면이 실제로 얼마나 오래 남는지 판단할 수도 없다. 재현 스크립트는 브라우저와 CDN을 사용하지 않고 조건 헤더를 직접 보냈다.

실제 배포에서 오래된 본문이 보인다면 먼저 조건 없는 응답에도 새 내용이 없는지, 조건부 요청에서만 304가 나오는지 구분한다. 전자는 배포 경로나 중간 캐시를 볼 이유가 되고, 후자는 응답 검증자와 파일 메타데이터를 살펴볼 단서다. 이 구분은 원인을 확정하는 공식이 아니라 조사 범위를 줄이기 위한 순서다.

# 본문은 파일에 저장하고 ETag와 Last-Modified를 비교한다.
curl -sS -D - -o first-body.txt https://example.com/sample.txt
# 실제 첫 응답의 ETag를 정확히 넣어 비교한다.
curl -sS -D - -o conditional-body.txt -H 'If-None-Match: "실제-ETag"' https://example.com/sample.txt

정적 자산의 내용이 바뀌면 URL도 바꾸는 빌드 방식은 동일 URL의 재검증 조건에만 기대는 상황을 줄여준다. 다만 HTML이 참조하는 이전 자산을 언제까지 남길지는 별도 문제다. 관련 배포 글에서는 HTML을 먼저 받은 방문자의 자산 요청이 실패하는 순서를 직접 확인했다.

python3 run-lab.py --output observations.json

python3 lab-nginx-boundaries.py --output new-observations.json