Nice programing

HTTP 304 Not Modified-responses에 캐시 제어 헤더가 포함되어야합니까?

nicepro 2021. 1. 7. 21:19
반응형

HTTP 304 Not Modified-responses에 캐시 제어 헤더가 포함되어야합니까?


나는 이것을 이해하려고 노력했고 비슷한 질문을 찾았지만 이것이 어떻게 작동하는지에 대한 100 % 이해는 아직 없습니다.

이미지 리소스 요청에 대해이 응답을받습니다.

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:04:04 GMT
    Expires Mon, 19 Oct 2009 09:06:05 GMT
    Cache-Control   public, max-age=120
    Etag    image_a70703fb393a60b6da346c112715a0abd54a3236
    Content-Disposition inline;filename="binary-216-420"
    Content-Type    image/jpg;charset=UTF-8
    Content-Length  4719

원하는 동작은 클라이언트가이를 120 초 동안 캐시 한 다음 서버에서 다시 요청하는 것입니다. 120 초 내에 서버에 요청이 전송되지 않습니다.

그런 다음 120 초 후에 요청이 전송되고 304 응답이 수신됩니다.

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:06:13 GMT

Request Headers
    Host    localhost:8080
    User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
    Accept  image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language en-us,no;q=0.8,sq;q=0.7,en;q=0.5,sv;q=0.3,nn;q=0.2
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  300
    Connection  keep-alive
    Referer http://localhost:8080/cms/site/0/en/home
    Cookie  JSESSIONID=768ABBE1A3BFABE3B535900233330650; versionsCssDisplayState=block; iceInfo=iceOn:false,activePortletKey:,icePagePanelX:1722,icePagePanelY:3
    If-None-Match   image_a70703fb393a60b6da346c112715a0abd54a3236

지금까지 모두 좋습니다. 하지만 다음 요청 (120 초)에서 리소스가 새로운 120 초 동안 캐시되어야한다고 생각했을 것입니다. 반면에 브라우저 (Firefox)에서 보는 것은이 시점부터 항상 리소스를 요청하고 304 응답을 수신한다는 것입니다.

304 응답에 캐시 제어 헤더를 첨부해야합니까? 사양에서 읽을 수있는 내용에서 캐시 제어 설정을 생략해야하고 캐시가 자동으로 120 초 동안 캐시를 캐시해야하는 것 같습니다.


이론적으로는 304에 대해 Cache-Control을 보낼 필요가 없습니다. 수신자는 원래 200에서받은 캐시 지시문을 계속 사용해야합니다. 그러나 실제로 발견 한대로 그렇지 않은 경우 Cache-Control을 계속 보내면 브라우저는 원래 보낸 캐시 지시문을 무시하고 자체 기본 휴리스틱으로 되돌아갑니다.

따라서 실제로는 200과 동일한 304에 동일한 Cache-Control을 포함해야합니다. 사양은 이전에 보낸 것과 다른 경우에만 304에 대해 전송하도록 요구합니다 ( 10.3.5 304 Not Modified 참조 ). -하지만 동일 할 때 반복하는 것을 확실히 금지하지는 않습니다.

그리고 다른 답변 (Structure 's)의 잘못된 점에 구체적으로 응답하려면 :

  1. 당신은 중간 캐시가 (즉, 자원에 대한 자신의 캐시 항목을 업데이트) 응답을 캐시합니다. 그들은 클라이언트가 If-Modified-Since와 같은 조건부 헤더를 포함했는지 여부에 따라 200 또는 304로 클라이언트의 요청에 적절하게 응답합니다.

  2. 120 초 ttl 304에 의해 새로 고쳐질 것입니다 (따라서 동일한 클라이언트가 최소 120 초 동안 동일한 리소스에 대해 다른 요청을해서는 안됩니다). 그리고 클라이언트는, 그들이 여전히 콘텐츠를 캐시있어 한만큼, 것입니다 당신이 304에 대응하기 위해 계속 수있는 자원에 대한 조건 요청을 계속한다.


RFC7232 는 RFC2616을 업데이트하여 다음과 같이 말합니다.

304 응답을 생성하는 서버는 동일한 요청에 대해 200 (OK) 응답으로 전송 된 다음 헤더 필드 중 하나를 생성해야합니다. Cache-Control, Content-Location, Date, ETag, Expires 및 Vary.


If I understand correctly then the browser is in fact caching for 120 seconds and your server is responding 304 Not Modified to subsequent If-Modified-Since requests. This "IMS" request occurs when the end-user accesses the same URL. At that time the browser can send an If-Modified-Since request. The browser wants to know if it is displaying stale content. This seems normal.

Upon receiving this request your server should reply 200 OK, 304 Not Modified (or a 4XX, if necessary).

I do not believe you should set your server to send a Cache-Control header with the 304 response for two reasons:
1. You do not want any intermediary caches to cache that 304 response (there is a possibility that they could)
2. The 120 second TTL will not be refreshed by the 304 response. The browser will retain the object for 120 seconds from the 200 OK response. After 120 seconds the browser should send a GET request, not an If-Modified-Since, so your server will respond with the bytes of the file and not just a 304 response.

Note that the browser will not request the file again automatically after 120 seconds unless the end-user specifically requests it via a page load or directly inputting the URL into their address bar (or unless you have a custom application that controls that functionality somehow).

Edited the first paragraph to read a bit better(hopefully)

ReferenceURL : https://stackoverflow.com/questions/1587667/should-http-304-not-modified-responses-contain-cache-control-headers

반응형