두 개의 후속 요청의 경우 다음 두 헤더 중 ETag 또는 Last-Modified 중 하나가 변경되면 브라우저에서 더 많은 가중치를 부여하는 것은 무엇입니까?
답변
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의 정보에서 이미 의심했던 수정 된 헤더를 보낼 때의 동작을 테스트했습니다. 내가 테스트 한 네 개의 클라이언트는 페이지가 새로 고쳐 졌거나 현재 프로세스에서 페이지를 처음 요청한 경우에만 조건부 요청을 보냈습니다.
답변
“OR”표현에 가깝지 않습니까? 의사 코드에서 :
if ETagFromServer != ETagOnClient || LastModifiedFromServer != LastModifiedOnClient
GetFromServer
else
GetFromCache
답변
=! 올바른 비교 연산자입니다. 변환은 작은 차이를 만들 수 있으므로 클라이언트는 서버에서받은 리터럴 문자열을 유지해야합니다. ‘새로운 것이 더 좋다’고 가정 할 수 없습니다.
왜? 서버 운영자가 자원의 잘못된 버전을 되 돌리는 경우를 고려하십시오. 되 돌린 버전은 이전 버전이지만 정확합니다.
클라이언트는 현재 서버에서 제공하는 버전을 사용해야합니다. 동일한 경우에만 캐시 된 버전을 사용할 수 있습니다. 따라서 서버는 ‘최신’이 아닌 동등성을 확인해야합니다.