(약함) ETags 및 Last-Modified

Question

RFC 2616 (HTTP/1.1)에 소개 된 ETag는 사양을 이해하는 한 Last-Modified-Header의 후속 버전입니다. 소프트웨어 설계자에게 캐시 재 유효성 확인 프로세스에 대해 더 많은 제어 권한을 부여하는 제안서.

RFC 2616에 따라 캐시 유효성 검사 헤더 (If-None-Match 및 If-Modified-Since)가 모두있는 경우 클라이언트 (예 : 브라우저)는 리소스가 있는지 확인하기 위해 ETag를 사용해야합니다 변경되었습니다. RFC 2616의 14.26 절에 따르면 서버는 If-None-Match-Header에 표시된 ETag가 변경되고 서버가 추가 If-Modified-Since-Header를 무시해야한다면 304 Not Modified로 응답해서는 안됩니다 ,있는 경우. 제시된 ETag가 일치하는 경우 Last-Modified-Header의 날짜가 그렇게 표시하지 않는 한 그는 요청을 수행해서는 안됩니다.

• 강한 :
  는

  이 절에서는 몇 가지 추측의 여지를 남긴다 (제시된의 ETag가 일치하는 경우, 서버는 ... 아니 GET-또는 HEAD 요청의 경우 수정 된 304 응답해야합니다) ETag는 '매번'변경 될 예정이며, 리소스가 변경됩니다. 따라서 ETag가 변경되지 않고 If-Modified-Since-Header가있는 요청에 대해 304 Not Modified로 응답해야하는 경우 ETag에 의하면 리소스가 일치하지 않기 때문에 약간의 모순이 있습니다. 수정되지 않았습니다. (비록,이 서버가 다시 같은 불변 리소스를 전송할 수 있기 때문에, 그 치명적인 아니다.)

• ...

... 오케이 이 글을 쓰는 동안, 질문은이 답변으로 끓어 내려고했습니다.

약한 ETags 때문에 위에 언급 한 (작은) 모순이 만들어졌습니다. 약한 ETag로 표시된 리소스는 ETag에는 없지만 변경되었을 수 있습니다. 따라서 약한 ETag의 경우 ETag가 변경되지 않았지만 If-Modified-Since에 표시된 날짜가 일치하지 않는 304 Not Modified로 대답하는 것이 잘못되었습니다. 맞습니까?

Answer 1

일반 (강력한) ETag와 약한 ETag의 차이는 일치하는 강력한 ETag는 파일이 바이트 단위로 동일하다는 것을 보장하지만 일치하는 약한 ETag는 내용이 의미 상 동일하다는 것을 나타냅니다. 따라서 파일 내용이 변경되면 약한 ETag도 변경되어야합니다.

제시된 시나리오에서 서버의 파일은 클라이언트의 캐시 된 복사본보다 새 파일 일 수 있습니다. 그러나 ETag가 일치하므로 캐시 된 복사본과 의미 적으로 동일하므로 304를 반환해도됩니다. 응답.