HTTP 304 Not Modified: 의미

이 오류의 의미와 확인 방법

• 브라우저 개발자 도구, API 클라이언트, 모니터링 도구 또는 검사기가 상태 304 Not Modified를 보고합니다.
• 응답에 캐싱 또는 validator 헤더는 포함되지만 리소스 본문은 없습니다.
• 브라우저는 캐시된 표현을 재사용하므로 페이지를 정상적으로 표시할 수 있습니다.
• API 클라이언트 또는 검사기가 조건부 캐싱을 올바르게 구현하지 않은 경우 빈 응답을 받은 것처럼 보일 수 있습니다.
• 결과는 웹사이트 전체가 아니라 하나의 URL 또는 리소스에만 적용될 수 있습니다.
• 클라이언트가 HTTP 엔드포인트에 도달하여 HTTP 응답을 받았으므로 DNS와 TLS는 여전히 정상적으로 작동할 수 있습니다.

가능성이 높은 순서의 주요 원인

1. 클라이언트가 조건부 요청을 보냈습니다. If-None-Match 또는 If-Modified-Since와 같은 요청 헤더가 캐시된 표현이 여전히 최신 상태인지 확인하도록 요청했습니다.
2. 리소스가 변경되지 않았습니다. 서버 또는 중간 계층이 ETag 또는 Last-Modified 값과 같은 제공된 validator와 일치하는 것을 확인하고 304를 올바르게 반환했습니다.
3. 브라우저, 프록시 또는 CDN이 일반적인 캐시 검증을 수행했습니다. 응답은 origin 애플리케이션이 아니라 중간 계층에서 생성되었을 수 있습니다.
4. 클라이언트 또는 모니터링 도구가 정상적인 캐시 응답을 오류로 표시했습니다. 일부 도구는 완전한 응답 본문을 기대하도록 설정되어 있어 저장된 사본을 재사용하지 못할 수 있습니다.
5. validator 또는 캐시 설정이 일관되지 않습니다. 애플리케이션 배포, 프록시 규칙 또는 origin 헤더가 오래되었거나 서로 충돌하거나 범위가 지나치게 넓은 캐시 validator를 생성하면 예상치 못한 결과가 발생할 수 있습니다.

HTTP 304 자체는 리디렉션, 인증 실패, rate limit 응답 또는 서버 장애가 아닙니다. 이러한 상태는 304에서 추측하지 말고 실제 상태, 헤더 및 로그를 통해 확인해야 합니다.

해결 방법

방문자용

1. 먼저 브라우저가 응답을 처리하도록 두세요. 일반적인 브라우저는 304를 받으면 캐시된 사본을 사용합니다. 페이지가 정상적으로 표시된다면 보통 별도의 조치가 필요하지 않습니다.
2. 정확한 URL을 확인하세요. 호스트명, 경로, 쿼리 문자열 및 프로토콜을 확인하세요. 서로 다른 URL에는 별도의 캐시된 표현이 있을 수 있습니다.
3. 표시된 콘텐츠가 오래되었거나 불완전한 경우 한 번만 다시 시도하세요. 반복해서 새로 고침하지 말고 브라우저의 일반적인 새로고침 기능을 사용하세요.
4. 필요한 경우에만 다른 클라이언트와 비교하세요. 한 브라우저에서는 오래된 콘텐츠가 표시되고 다른 브라우저에서는 그렇지 않다면, 영향을 받은 URL, 대략적인 시간 및 클라이언트 동작을 기록하여 사이트 소유자에게 전달하세요.
5. 리소스를 로드할 수 없으면 사이트 소유자에게 문의하세요. URL과 타임스탬프를 전달하되, 비밀번호, 쿠키, authorization 헤더 또는 기타 개인 정보는 공유하지 마세요.

개발자 및 사이트 소유자용

1. 전체 요청 및 응답 컨텍스트를 수집하세요. HTTP 메서드, 관련 쿼리 파라미터를 포함한 전체 URL, 상태, 요청 validator, 응답 validator, Cache-Control, Vary 및 프록시 또는 CDN 헤더를 기록하세요. 공유하기 전에 인증 정보와 개인 데이터를 삭제하세요.
2. 요청이 조건부인지 확인하세요. If-None-Match 또는 If-Modified-Since를 찾으세요. 304는 일반적으로 클라이언트가 검증할 캐시된 표현을 보유한 경우에 의미가 있습니다.
3. 응답을 생성한 계층을 확인하세요. 304가 브라우저, 로컬 또는 공유 프록시, CDN, reverse proxy, 웹 서버 또는 애플리케이션 중 어디에서 반환되었는지 확인하세요. 가능한 경우 해당 구성 요소의 요청 식별자와 타임스탬프를 사용하세요.
4. validator를 리소스와 비교하세요. ETag 또는 Last-Modified가 요청된 표현을 정확히 나타내는지 확인하고, 관련된 경우 적절한 Vary 정책이 콘텐츠 협상을 포괄하는지 확인하세요.
5. 현재 본문이 필요하면 무조건부 요청을 테스트하세요. 권한이 있는 진단 클라이언트를 사용하거나 통제된 테스트에서 조건부 요청 헤더를 일시적으로 생략하세요. 이는 읽기 전용 비교이지만 서비스의 일반적인 접근 제어를 따르고 신뢰할 수 없는 도구에 민감한 헤더를 보내지 마세요.
6. 최근 캐시 및 배포 변경 사항을 검토하세요. 애플리케이션 릴리스, asset 생성, 프록시 또는 CDN 규칙, 압축 및 콘텐츠 협상, 라우팅, 캐시 무효화 동작을 확인하세요. 전역 설정을 즉시 변경하기보다 특정 경로에 영향을 준 변경 사항에 집중하세요.
7. 가장 범위가 좁고 안전한 수정 사항을 적용하세요. 불일치를 파악한 후에만 validator, 캐시 정책 또는 중간 계층 규칙을 수정하세요. 하나의 경로 또는 표현에만 문제가 있는 경우 전역적으로 캐싱을 비활성화하지 마세요.
8. 동일한 요청 경로를 다시 테스트하세요. 조건부 요청과 새로운 요청을 모두 테스트한 다음, 관련 경로와 요청 메서드가 의도한 상태 및 표현을 계속 반환하는지 확인하세요.

예방 및 해결 확인 방법

• 클라이언트가 캐시된 표현을 사용할 수 없는 경우가 아니라면 304를 모니터링에서 예상되는 캐시 검증 결과로 처리하세요.
• 배포 후 중요한 경로를 일반 요청과 조건부 요청으로 모두 테스트하세요.
• ETag, Last-Modified, Cache-Control 및 Vary 동작을 의도에 맞게 설정하고 문서화하세요.
• 제공되는 표현이 변경될 때 관련 콘텐츠 협상 변형을 포함하여 캐시 validator도 변경되도록 하세요.
• 경로별 및 캐시 계층별 상태 비율을 모니터링하여 예상치 못한 304 패턴과 일반적인 브라우저 트래픽을 구분하세요.
• 가능한 경우 프록시, CDN, 웹 서버 및 애플리케이션 설정을 버전 관리하세요.
• 정제된 요청 식별자와 타임스탬프를 충분히 오래 보관하여 보고된 문제를 응답을 생성한 계층과 연결할 수 있도록 하세요.

자주 묻는 질문