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 apache-2.4 last-modified

— zrz
소스

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 헤더와 같은 것들은 캐시를 무효화합니다. 헤더가 캐시 친화적으로 보이지 않습니다.

— mc0e
소스

요청 된 파일은 정적 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하려면 필요한 페이지에만 요청 하십시오. 모든 리소스를 다시 확인할 필요는 없으며 그렇게하면 대역폭을 낭비하게됩니다.

— 토륨 BR
소스

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

— zrz

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

— ThoriumBR

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

— zrz

@ThoriumBR 내가 당신을 올바르게 해석했다면, 당신의 대답은 모두 여기에 맞지 않습니다; 캐시 없음 (스토어 없음)은 "캐시하지 않음"을 의미하지 않으며 내용이 변경되지 않은 경우 304가 될 수 있습니다. 실제로 OP는 이것을 예상했지만 etag 문제로 인해 얻지 못했습니다. must-revalidate는 오래된 컨텐츠를 처리하는 방법과 관련이 있으며 항상 "데이터를 다시 모두"보내는 것은 아닙니다.

— Nick