우선 순위는 무엇입니까 : ETag 또는 Last-Modified HTTP 헤더?


83

두 개의 후속 요청의 경우 다음 두 헤더 중 ETag 또는 Last-Modified 중 하나가 변경되면 브라우저에서 더 많은 가중치를 부여하는 것은 무엇입니까?

답변:


90

RFC 2616 섹션 13.3.4 에 따르면 HTTP 1.1 클라이언트는 캐시 조건부 요청에서 ETag를 사용해야하며 ETag와 Last Modified가 모두있는 경우 둘 다 사용해야합니다 (SHOULD). ETag 헤더는 서버에 의해 명시 적으로 약하다고 선언되지 않는 한 강력한 유효성 검사기로 간주됩니다 (13.3.3 절 참조). 반면 Last Modified 헤더는 해당 헤더와 Date 헤더 사이에 최소 1 분의 차이가없는 한 약한 것으로 간주됩니다. 그러나 서버는 둘 중 하나를 보낼 필요가 없습니다 (하지만 가능하다면 반드시 전송해야합니다).

클라이언트는 헤더가 변경되었는지 확인하기 위해 헤더를 확인하지 않습니다. 다음 조건부 요청에서 맹목적으로 사용합니다. 요청 된 콘텐츠 또는 304 Not Modified 응답을 보낼지 여부를 평가하는 것은 서버의 몫입니다. 서버가 하나만 보내면 클라이언트는 그 하나만 사용합니다 (하지만 강력한 유효성 검사기 만 Range 요청에 유용합니다). 물론, 중간 캐시 (캐시 제어 지시문을 통해 캐시되지 않는 한)와 서버가 헤더에 대해 작동하는 방식에 대한 재량도 있습니다. RFC는 검증자가 일치하지 않는 경우 304 Not Modified를 반환해서는 안된다고 명시하고 있지만 헤더 값은 서버에서 생성되기 때문에 약간의 여유가 있습니다.

실제로 Chrome, FireFox 및 IE 7+는 모두 가능한 경우 두 헤더를 모두 전송합니다. 또한 RFC의 정보에서 이미 의심했던 수정 된 헤더를 보낼 때의 동작을 테스트했습니다. 내가 테스트 한 네 개의 클라이언트는 페이지가 새로 고쳐 졌거나 현재 프로세스에서 페이지를 처음 요청한 경우에만 조건부 요청을 보냈습니다.


1
훌륭한 대답, 토마스. 공식 사양을 제공하고 현재 브라우저 구현에 대해 논의 해 주셔서 감사합니다.
dthrasher 2009

1
14.26 절에서 인용하면 , 서버는 자원의 수정 날짜가 요청의 If-Modified-Since 헤더 필드에 제공된 날짜와 일치하지 않기 때문에 필요한 경우가 아니면 요청 된 방법을 수행해서는 안됩니다 . If-Modified-Since가 우선하는 것처럼 보입니다.
Vicary

20

"OR"표현에 가깝지 않습니까? 의사 코드에서 :

if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
   GetFromServer
else
   GetFromCache

4
마지막으로 수정 된 타임 스탬프는 다음과 같이 다르게 비교되어야한다고 생각합니다. if ETagFromServer! = ETagOnClient || LastModifiedFromServer> LastModifiedOnClient
RoyM 2014-08-31

ETag가 약할 수 있기 때문에 AND 문입니다.이 경우 의미 상 동등한 엔터티를 가질 수 있고 마지막으로 수정 된 헤더로 돌아갈 수 있습니다. 그림이 다시 인코딩 될 수 있고 원본과 다시 인코딩이 바이트 동일하지 않음에도 불구하고 동일하다고 말하고 싶은 상황을 고려하십시오. 이 경우 우리는 마지막 수정 된 것을 폴백으로 사용하기를 원하기 때문에 둘 다 일관성이 있어야합니다
ParoX

8

=! 올바른 비교 연산자입니다. 변환은 작은 차이를 만들 수 있으므로 클라이언트는 서버에서받은 리터럴 문자열을 유지해야합니다. '새로운 것이 더 좋다'고 가정 할 수 없습니다.

왜? 서버 운영자가 자원의 잘못된 버전을 되 돌리는 경우를 고려하십시오. 되 돌린 버전은 이전 버전이지만 정확합니다.

클라이언트는 현재 서버에서 제공하는 버전을 사용해야합니다. 동일한 경우에만 캐시 된 버전을 사용할 수 있습니다. 따라서 서버는 '최신'이 아닌 동등성을 확인해야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.