Cache Control max age에 대해서

나건일·2024년 6월 22일

Cache RFC http web

web

목록 보기

2/2

발생한 이슈

CDN에 업로드된 파일에 오류가 있어서 파일을 수정한 뒤 cdn purge까지 진행을 했는데, 샘플앱에서 여전히 업데이트 되기 전에 발생하는 오류가 발생했습니다.

AOS의 경우에는 앱 캐시를 삭제할수 있어서 앱 캐시를 삭제하면 정상적으로 동작했지만, IOS에서는 앱을 완전히 삭제후 재 설치 한 이후에나 정상적으로 동작했습니다.

WKWebView 구조상 캐싱을 기본적으로 하도록 되어 있고, 캐싱을 하지 않게 만드는 방법은 없기 때문에, 브라우저에서 Cache-Control max-age 설정을 해두는 것이 최선으로 보여집니다.

max-age만 설정되었을 때 캐시 동작 방식(그림)

s-maxage와 max-age가 설정되었을 때 캐시 동작 방식(그림)

Web Cache에 대해서 정리한 문서

https://velog.io/@gunilna/Web-Cache%EC%97%90-%EB%8C%80%ED%95%B4%EC%84%9C

그래서, 왜 안 됐는데?

Cache-Control과 Expired를 설정하지 않았었기 때문에, 휴리스틱 만료 시간을 사용하게 됩니다.
휴리스틱 만료 시간의 계산법은 다음과 같습니다. (RFC 문서 참조)

(now() - Last-Modified) * 0.10

firefox의 경우는 최대 일주일이라고 합니다 (참고)

그래서 CDN에서 purge를해서 CDN캐시를 지웠음에도, 웹뷰 캐시에 남아있는 정보는 휴리스틱 만료시간이 지나지 않았기 때문에 캐시가 신선한(fresh)상태로 판단하고, 캐시된 정보를 계속 사용한 것으로 판단됩니다.

304 Not Modified 일 때 서버에서 돌려주는 값은?

서버가 200응답 대신 304 응답을 생성하려면, 다음의 헤더 필드중 하나 이상을 반드시 포함해야 합니다.

Content-Location, Date, ETag, Vary
Cache-Control, Expires

304 Not Modified의 목적이 수신자가 하나이상의 캐시를 가지고 있을 때 전달되는 정보를 최소하하는 것이기 때문에, 발신자는 캐시 업데이트를 가이드하기 위한 목적이 아니라면 위에 나열된 필드 이외의 메타데이터를 생성해서는 안 됩니다. (예시: 응답에 Etag 필드가 없는 경우 Last-Modified가 유용할 수 있음).

원본

The server generating a 304 response MUST generate any of the following header fields that would have been sent in a 200 (OK) response to the same request:

Content-Location, Date, ETag, and Vary

Cache-Control and Expires (see [CACHING])

Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations, a sender SHOULD NOT generate representation metadata other than the above listed fields unless said metadata exists for the purpose of guiding cache updates (e.g., Last-Modified might be useful if the response does not have an ETag field).