서비스 작업자 응답 캐시 헤더

Question

서비스 담당자가 응답의 캐시 헤더와 관련하여 어떻게 작동하는지 파악하려고합니다. 필자는 이제 몇 명의 서비스 작업자를 구현했지만 헤더를 캐싱하는 것에 대해 걱정할 필요가 없었습니다. 얼마나 많은 항목을 캐싱해야하는지 등등. 이제는 엔터프라이즈 프로덕션 사이트에서이 항목을 실제로 구현하므로 실제적으로 중요합니다.

기본적으로 서비스 작업자를 사용할 때 http 캐시가 완전히 무시됩니까?

우리는 http 캐시와 같이 자원 만료/무효화를 처리하기위한 프레임 워크를 구축해야합니까? 아니면 내가 쓰레기를 말하는거야?

누군가가이 사실에 대해 설명해 줄 수 있다면 도움이 될 것입니다. 내가 보는 방법에는 3 가지 시나리오가 있습니다 :

A). 네트워크 요청 => 서비스 작업자 가져 오기 => (브라우저 캐시?) < => 서버

B). 네트워크 요청 < => (브라우저 캐시?) < => 서비스 종사자 가져 오기 < => 서버

C). 네트워크 요청 => 서비스 종사자 가져 오기 < => 서버

로컬로 테스트 해본 결과 C) 인 것 같습니다. 올바른 구현이므로 개발자가 제어를 위해 캐시 헤더/기간 추상화를 희생했습니다.

저는 이것으로 문제가 없지만 서비스 직원의 캐싱 헤더를 읽고 준수하기위한 프레임 워크를 빌드하기 전에 명확히하기를 원합니다.

Answer 1

A)가 올바른 모델입니다. 서비스 작업자가 페이지를 제어하면 브라우저 캐시 또는 네트워크를 확인하기 전에 모든 네트워크 요청이 서비스 작업자의 fetch 이벤트 처리기를 트리거합니다.

차례로 fetch()을 통해 명시 적으로 또는 cache.add()/cache.addAll()을 통해 명시 적으로 네트워크 작업자가 네트워크 요청을하면 브라우저의 "전통적인"캐시가 먼저 응답을받습니다. 서버에 대한 네트워크 요청은 브라우저 캐시에 유효한 응답이없는 경우에만 수행됩니다.

이 기능은 사용자의 편의를 위해 때때로 작동하며, 동작을 예상하지 않는 경우 가끔씩 미묘한 버그에 노출 될 수 있습니다.

https://jakearchibald.com/2016/caching-best-practices/에 대한 자세한 설명은 things to avoid과 ways to take advantage of this behavior입니다.

Answer 2

요청 구성 방법에 따라 다릅니다. Fetch API를 사용하면 요청이 브라우저 HTTP 캐시와 상호 작용하는 방식을 제어 할 수 있습니다.

예를 들어 요청의 캐시 모드를 no-store으로 설정하여 HTTP 캐시를 무시할 수 있습니다. 또는 당신은 오래된 경우에도 캐시 된 응답을 반환합니다 force-cache 그래서 브라우저에 요청의 캐시 모드를 설정할 수 있습니다 : 기본 요청의 캐시 모드에 의해

fetch("some.json", {cache: "force-cache"}) 
    .then(function(response) { /* consume the response */ }); 

이 default입니다. 이 경우 요청은 평소와 같이 작동합니다. 서비스 전문가가 하드 코딩 된 응답을 반환하는 대신 실제로 요청을 수행하는 경우에만 해당됩니다.

자세한 내용은 Fetch Standard, Request.cache MSN page 및 Using Service Workers MDN page을 확인하십시오.