Last-modified가 If-modified-since와 일치하는 동안 Apache가 200 OK를 보내는 이유는 무엇입니까?


10

캐싱 전략과 관련하여 기본적인 동작을 시도하고 있습니다. 파일을 캐시하고 매번 서버와 다시 유효성을 검사해야합니다. 그래서 아파치가 304를 다시 보내길 원합니다.

각 브라우저 새로 고침마다 발생하는 대화 상자는 다음과 같습니다.

Status Code:200 OK

Request Headers

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip,deflate,sdch
Accept-Language:fr-FR,fr;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Cookie: ...
Host:...
If-Modified-Since:Tue, 14 Oct 2014 15:10:37 GMT
If-None-Match:"1461-505636af08fcd-gzip"
User-Agent:Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Response Headers

Accept-Ranges:bytes
Cache-Control:No-cache
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:1412
Content-Type:text/html
Date:Tue, 14 Oct 2014 16:58:05 GMT
ETag:"1461-505636af08fcd-gzip"
Keep-Alive:timeout=5, max=99
Last-Modified:Tue, 14 Oct 2014 15:10:37 GMT
Server:Apache/2.4.6 (Ubuntu)
Vary:Accept-Encoding

(이것은 Chrome devtools에서 왔으며 캐시 사용 안함을 선택하지 않았습니다)

응답에 Cache-Control : No-cache 헤더가 포함되어 있고 If-modified-since 헤더가 Last-modified와 일치 함을 알 수 있습니다. ETag도 일치합니다.

이 경우 Apache가 304를 보내면 안됩니까?

편집하다

아파치에서 ETag 비활성화

 Header  unset ETag

캐싱 동작을보다 예측 가능하게 만듭니다 ...


Cache-Control:max-age=0캐시를 비활성화 했다고 생각 하므로 Cache-Control:No-cache응답이 표시됩니다.
ThoriumBR

w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1 에서 아파치 구성에서 Cache-Control : No-cache를 명시 적으로 설정했기 때문에 각 요청에 대해 유효성을 다시 확인한다는 것을 이해합니다. 유효성 재확인은 파일을 다시 보내는 것을 의미합니까? 나는 그것이 200인지 304인지를 결정하기 위해 If-modified-since를 사용해야한다고 말할 것이다.
zrz

답변:


8

이것은 오래된 버그 인 것 같습니다 Header unset ETag. 왜 차이가 있는지 설명 합니다.

Apache 2.4.0 이상에서는 헤더에 표시된 것처럼 압축 방법 이름을 ETag에 자동으로 추가하고 304 응답을 방지합니다.

최신 버전의 mod_deflate는 이 동작을 제어하는 ​​데 사용할 수 있는 DeflateAlterETag 를 지원합니다 .

DeflateAlterETag NoChange

3
이것은 정확하지만 Apache 2.4에는 해당 옵션이없고 Apache 2.5 만 포함되어 있습니다. 그러나 개인적으로 Apache가 파일 내용이 아닌 마지막 수정 날짜를 기준으로하기 때문에 유용한 ETag를 찾지 못했습니다. 따라서 ETag를 끄면 마지막 수정 날짜를 기반으로하는 If-Modified-Since 헤더로 돌아갑니다. Apache에서 ETag를 크기, 마지막 수정 및 / 또는 inode (크기 및 마지막 수정이 기본값)로 변경하도록 변경할 수 있지만 파일 내용의 체크섬을 기반으로 ETag를 계산하는 옵션을 추가 할 때까지, 제한된 사용 IMHO. 그래서 나는 그들을 끕니다.
Barry Pollard

1
@BazzaDP 이해가 되네요. 2.5 또한 DeflateAlterETag Remove그렇게 할 수 있는 옵션이 있습니다
Mathias R. Jessen

0

이것은 요청에서 조금 이상하다는 점에서 두드러집니다.

Cache-Control:max-age=0

더 중요한 것은 반환 된 내용이 html이라는 것을 알 수 있습니다. 동적으로 생성되고 있습니까? Apache는 304 응답을 보낼 수 있지만 정적 컨텐츠를 제공하지 않는 한 Apache가 해당 호출을 수행하는 것은 아니며 애플리케이션 논리에 달려 있습니다. 예를 들어 대부분의 PHP 응용 프로그램은 그러한 것들에 대한 지원이 제한적입니다.

캐싱 앱이 수정 시간, 전자 태그 등을 확인할 수 있지만 응용 프로그램과 요청 헤더 모두 캐시 친화적 인 경우에만 프런트 엔드 캐시가 도움이 될 수 있습니다. 예를 들어 응용 프로그램은 내용이 캐시 가능하다는 것을 나타 내기 위해 적절한 헤더를 설정해야하며 요청의 Cache-control 헤더와 같은 것들은 캐시를 무효화합니다. 헤더가 캐시 친화적으로 보이지 않습니다.


요청 된 파일은 정적 html 파일이며 Apache가 수정 시간을 올바르게 얻습니다. (마지막 수정 : 화, 2014 년 10 월 14 일 15:10:37 GMT). URL을 입력하고 Enter 키를 누르면 max-age = 0 헤더가 크롬이 보낸 요청에 있습니다. 이전 응답으로 인해 있습니까?
zrz

Chrome이 자동으로 Cache-Control : max-age = 0을 요청에 추가한다는 것을 읽었습니다 (Chrome을 처음로드 할 때를 제외하고는 URL을 입력하고 Enter 키를 누르십시오). 그러나 그것은 다른 서버에 영향을 미치지 않는 것 같습니다 (요청에서 max-age = 0으로도 CDN이 304를 보냅니다).
zrz

@zrz : 중간 캐싱 제한은 디버깅 할 때 매우 유용하지만 성능이 저하 될 수 있습니다. 크롬이하는 일에서 읽은 내용의 맥락을 확인하십시오. 아파치가하는 일에 관해서는, 그것은 꽤 구성 가능합니다. 캐시 제어는 오리진 서버가 아닌 중개 캐시에 대한 지시 사항입니다. 그러나 아파치는 중개 캐시 역할을 할 수 있으며 모든 종류의 작업을 수행하도록 구성 할 수 있습니다. 캐싱 방지 지침을 수행하면 원래 서버에서 기대하는 것과 같은 동작을 얻을 수 있다고 생각합니다.
mc0e

0

Apache를로 구성한 경우 Cache-Control:No-cacheApache는 HTTP 304 Not modified클라이언트 로 를 보내지 않습니다 .

일부 요청을 다시 확인 Cache-Control:No-cache하려면 필요한 페이지에만 요청 하십시오. 모든 리소스를 다시 확인할 필요는 없으며 그렇게하면 대역폭을 낭비하게됩니다.


"재확인"이라는 용어로 혼동되는 것 같습니다. 나에게 그것은 그것이 304인지 확인하는 것을 의미합니다. 내가 틀렸습니까?
zrz

당신은 잘못. 재확인은 데이터를 모두 클라이언트로 다시 보내고 이미 동일한 정보를 가지고 있더라도 모든 것을 다시 읽도록 강제하는 것입니다. 기본적으로 모든 클라이언트에서 캐시를 비활성화합니다.
ThoriumBR

많은 설명이 있습니다. 마지막으로 아파치는 Apache가 일부 리소스 (예 : png)에 대해 304를 보내지 만 Cache-Control은 응답에서 No-cache를 설정하지 않고 요청에서 max-age = 0으로 설정한다는 점을 명심해야합니다. 어떤 단서?
zrz

@ThoriumBR 내가 당신을 올바르게 해석했다면, 당신의 대답은 모두 여기에 맞지 않습니다; 캐시 없음 (스토어 없음)은 "캐시하지 않음"을 의미하지 않으며 내용이 변경되지 않은 경우 304가 될 수 있습니다. 실제로 OP는 이것을 예상했지만 etag 문제로 인해 얻지 못했습니다. must-revalidate는 오래된 컨텐츠를 처리하는 방법과 관련이 있으며 항상 "데이터를 다시 모두"보내는 것은 아닙니다.
Nick
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.