버그가 있는 서비스 워커 삭제

버그가 있는 서비스 워커가 배포되는 경우가 있으며 문제가 있습니다 예를 들어, 서비스 워커는 등록 시 파싱되어 성공적으로 설치를 완료할 수 있습니다. 그러나 fetch 이벤트의 버그가 있는 코드로 인해 요청에 응답하지 않을 수 있습니다. 빈 페이지가 표시됩니다. 또 다른 가능성은 페이지 마크업이 적극적으로 캐시되어 서비스 워커가 후속 방문에 대해 Cache 인스턴스에서 오래된 마크업 응답만 반환합니다.

서비스 워커가 역효과를 낳을 수 있는 방법에는 여러 가지가 있지만, 이건 프로덕션 웹사이트에 가면 정말 무서운 문제입니다. 그렇다고 해서 모든 것이 손실되는 것은 아닙니다. 상황을 해결하고 평소에 복구하는 방법에는 여러 가지가 있습니다.

일반적으로 버그가 있는 서비스 워커를 처리하려면 기본 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) 서비스 워커를 배포해야 하는 경우 정확히 무엇이 잘못되었는지 파악하는 데 시간이 걸립니다. 차후에는 서비스 워커가 예상하는 요청만 처리하도록 해야 합니다. 스테이징에서 자주 테스트하고 신뢰할 수 있는 경우에만 업데이트를 배포하세요.