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>
엘리먼트가 해당 요청을 시작했다면, 응답 객체는 이미지 데이터를 필요로 합니다. 보안적인 이유들로, 여기엔 몇가지 전역 규칙이 존재합니다.
- You can only return
Response
(en-US) objects oftype
(en-US) "opaque
" if thefetchEvent.request
(en-US) object'smode
(en-US) is "no-cors
". This prevents the leaking of private data. - You can only return
Response
(en-US) objects oftype
(en-US) "opaqueredirect
" if thefetchEvent.request
(en-US) object'smode
(en-US) is "manual
". - You cannot return
Response
(en-US) objects oftype
(en-US) "cors
" if thefetchEvent.request
(en-US) object'smode
(en-US) is "same-origin
".
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'sResponse.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