버그가 있는 서비스 워커가 배포되는 경우가 있으며
문제가 있습니다
예를 들어, 서비스 워커는 등록 시 파싱되어 성공적으로 설치를 완료할 수 있습니다.
그러나 fetch 이벤트의 버그가 있는 코드로 인해 요청에 응답하지 않을 수 있습니다.
빈 페이지가 표시됩니다. 또 다른 가능성은 페이지 마크업이 적극적으로 캐시되어
서비스 워커가 후속 방문에 대해 Cache 인스턴스에서 오래된 마크업 응답만 반환합니다.
서비스 워커가 역효과를 낳을 수 있는 방법에는 여러 가지가 있지만, 이건 프로덕션 웹사이트에 가면 정말 무서운 문제입니다. 그렇다고 해서 모든 것이 손실되는 것은 아닙니다. 상황을 해결하고 평소에 복구하는 방법에는 여러 가지가 있습니다.
노옵스(no-ops) 서비스 워커 배포
일반적으로 버그가 있는 서비스 워커를 처리하려면 기본
fetch 이벤트 핸들러 없이 즉시 설치하고 활성화하는 no-op 서비스 워커:
// sw.js
self.addEventListener('install', () => {
// Skip over the "waiting" lifecycle state, to ensure that our
// new service worker is activated immediately, even if there's
// another tab open controlled by our older service worker code.
self.skipWaiting();
});
self.addEventListener('activate', () => {
// Optional: Get a list of all the current open windows/tabs under
// our service worker's control, and force them to reload.
// This can "unbreak" any open windows/tabs as soon as the new
// service worker activates, rather than users having to manually reload.
self.clients.matchAll({
type: 'window'
}).then(windowClients => {
windowClients.forEach((windowClient) => {
windowClient.navigate(windowClient.url);
});
});
});
이 서비스 워커는 다음을 호출하여 즉시 설치하고 활성화합니다.
install 이벤트의 self.skipWaiting()
원하는 경우 activate 이벤트에 추가 코드를 배포하여 서비스 워커가 제어하는 WindowClient로 열려 있는 다른 탭을 강제로 새로고침할 수 있습니다.
노옵스(no-ops) 서비스 워커에는 fetch 이벤트 핸들러가 포함되지 않는 것이 매우 중요합니다.
서비스 워커가 요청을 처리하지 않을 때,
이러한 요청은 마치 서비스 워커가 없는 것처럼 브라우저로 전달됩니다.
노옵스(no-ops) 서비스 워커가 배포되면 버그가 있는 서비스 워커를 수정하여 나중에 업데이트로 배포할 수 있습니다.
브라우저가 서비스 워커를 HTTP 캐시에 배치하지 못하도록 강력한 보호 장치를 갖추고 있으며, 그리고 업데이트를 위해 서비스 워커 콘텐츠의 바이트 단위 검사를 수행하기 때문에 이 접근 방식이 효과가 있습니다. 이러한 기본값을 사용하면 버그가 있는 서비스 워커를 위한 노옵스(no-ops) 교체품을 배포하여 문제를 신속하게 해결할 수 있습니다.
취해야 할 추가 조치
노옵스(no-ops) 서비스 워커를 배포하는 것만으로도 버그가 있는 서비스 워커를 무력화할 수 있습니다. 필요한 경우 추가 조치를 취할 수 있습니다.
이전 서비스 워커의 URL을 모르는 경우 어떻게 해야 할까요?
이전에 설치된 서비스 워커의 URL을 알 수 없는 경우가 있습니다. 이는 버전이 지정되어 있기 때문일 수 있습니다 (예: 파일 이름에 해시가 포함되어 있음). 이 경우 등록되었을 수 있는 각 이전 서비스 워커의 URL과 일치하는 노옵스(no-ops) 서비스 워커를 배포하기가 어려울 수 있습니다. 이는 권장사항을 따르지 않습니다. 개발자들은 배포된 모든 서비스 워커 버전에 대한 모든 해시를 기억하지 못할 가능성이 높습니다.
다행히 유용한 HTTP 요청 헤더가 서비스 워커 스크립트에 대한 요청과 함께 전송됩니다.
Service-Worker
웹 서버에서 이 헤더를 확인하고 요청을 가로채 노옵스(no-ops) 서비스 워커를 대신 제공하세요.
이 기능을 실행하는 작업은 사용된 웹 서버와 백엔드 스택에 따라 다르므로 이를 수행하는 방법은 관련 언어의 문서를 참조하세요.
향후 서비스 워커 배포의 경우 버전이 지정되지 않은 애셋 이름 (예: sw.js)을 사용하세요.
이렇게 하면 나중에 상황이 훨씬 덜 복잡해집니다.
Clear-Site-Data 헤더 설정
일부 브라우저는 특정 출처의 서비스 워커가
값이 'storage'인 Clear-Site-Data 응답 헤더가 설정되었습니다.
그러나 이 접근 방식에서 몇 가지 알아야 할 사항이 있습니다.
- 이 작업을 수행하면 연결된 원본의 모든 스토리지가 삭제된다는 점에 유의하세요. 여기에는
localStorage, IndexedDB,sessionStorage, 기타 스토리지가 포함됩니다 (원본의 HTTP 캐시는 포함되지 않음). - 이 헤더는 일부 브라우저에서만 지원됩니다.
이 헤더에 대한 지원은 전체가 아니므로 문제 해결에 전적으로 의존할 수 없습니다.
따라서 노옵스(no-ops) 서비스 워커를 배포하는 것 외에 취해야 할 조치로 Clear-Site-Data를 보는 것이 가장 좋습니다.
영구적인 손상이 아님
버그가 있는 서비스 워커(특히 크고 잘 알려진 웹사이트의 경우)가 사용자 경험을 방해한다면 두려울 수 있습니다. 하지만 피해는 일시적이며 되돌릴 수 있습니다.
상황을 해결하기 위해 노옵스(no-ops) 서비스 워커를 배포해야 하는 경우 정확히 무엇이 잘못되었는지 파악하는 데 시간이 걸립니다. 차후에는 서비스 워커가 예상하는 요청만 처리하도록 해야 합니다. 스테이징에서 자주 테스트하고 신뢰할 수 있는 경우에만 업데이트를 배포하세요.