이 페이지는 영어로부터 커뮤니티에 의하여 번역되었습니다. MDN Web Docs에서 한국 커뮤니티에 가입하여 자세히 알아보세요.

FetchEvent.respondWith()

Experimental: This is an experimental technology
Check the Browser compatibility table carefully before using this in production.

FetchEvent의 respondWith() 메소드는 브라우저의 기본 fetch 핸들링을 막고, 당신 스스로 Response (en-US)에 대한 promise를 제공할 수 있게 허락합니다.

대부분의 상황에서 당신은 수신자가 이해하는 어떠한 응답이라도 제공할 수 있습니다. 예를 들어, <img> 엘리먼트가 해당 요청을 시작했다면, 응답 객체는 이미지 데이터를 필요로 합니다. 보안적인 이유들로, 여기엔 몇가지 전역 규칙이 존재합니다.

Specifying the final URL of a resource

From Firefox 59 onwards, when a service worker provides a Response (en-US) to FetchEvent.respondWith(), the Response.url (en-US) value will be propagated to the intercepted network request as the final resolved URL. If the Response.url (en-US) value is the empty string, then the FetchEvent.request.url (en-US) is used as the final URL.

In the past the FetchEvent.request.url (en-US) was used as the final URL in all cases. The provided Response.url (en-US) was effectively ignored.

This means, for example, if a service worker intercepts a stylesheet or worker script, then the provided Response.url (en-US) will be used to resolve any relative @import or importScripts() (en-US) subresource loads (bug 1222008).

For most types of network request this change has no impact because you can't observe the final URL. There are a few, though, where it does matter:

  • If a fetch() (en-US) is intercepted, then you can observe the final URL on the result's Response.url (en-US).
  • If a worker script is intercepted, then the final URL is used to set self.location and used as the base URL for relative URLs in the worker script.
  • If a stylesheet is intercepted, then the final URL is used as the base URL for resolving relative @import loads.

Note that navigation requests for Windows and iframes (en-US) do NOT use the final URL. The way the HTML specification handles redirects for navigations ends up using the request URL for the resulting Window.location. This means sites can still provide an "alternate" view of a web page when offline without changing the user-visible URL.

Syntax

fetchEvent.respondWith(
  // Promise that resolves to a Response.
​)

Parameters

A Promise for a Response (en-US).

Return value

Void.

Exceptions

Exception Notes
NetworkError A network error is triggered on certain combinations of FetchEvent.request.mode (en-US) and Response.type (en-US) values, as hinted at in the "global rules" listed above.

Examples

This fetch event tries to return a response from the cache API, falling back to the network otherwise.

addEventListener('fetch', event => {
  // Prevent the default, and handle the request ourselves.
  event.respondWith(async function() {
    // Try to get the response from a cache.
    const cachedResponse = await caches.match(event.request);
    // Return it if we found one.
    if (cachedResponse) return cachedResponse;
    // If we didn't find a match in the cache, use the network.
    return fetch(event.request);
  }());
});

Specifications

Specification
Service Workers
# fetch-event-respondwith

Browser compatibility

BCD tables only load in the browser

See also