This is an experimental technology
Check the Browser compatibility table carefully before using this in production.
The respondWith()
method of FetchEvent
prevents the browser's default fetch handling, and allows you to provide a promise for a Response
yourself.
In most cases you can provide any response that the receiver understands. For example, if an <img>
initiates the request, the response body needs to be image data). For security reasons, there are a few global rules:
Response
objects of type
"opaque
" if the fetchEvent.request
object's mode
is "no-cors
". This prevents the leaking of private data.Response
objects of type
"opaqueredirect
" if the fetchEvent.request
object's mode
is "manual
".Response
objects of type
"cors
" if the fetchEvent.request
object's mode
is "same-origin
".From Firefox 59 onwards, when a service worker provides a Response
to FetchEvent.respondWith()
, the Response.url
value will be propagated to the intercepted network request as the final resolved URL. If the Response.url
value is the empty string, then the FetchEvent.request.url
is used as the final URL.
In the past the FetchEvent.request.url
was used as the final URL in all cases. The provided Response.url
was effectively ignored.
This means, for example, if a service worker intercepts a stylesheet or worker script, then the provided Response.url
will be used to resolve any relative @import
or importScripts()
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:
fetch()
is intercepted, then you can observe the final URL on the result's Response.url
.self.location
and used as the base URL for relative URLs in the worker script.@import
loads.Note that navigation requests for Windows
and iframes
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.
fetchEvent.respondWith( // Promise that resolves to a Response. )
Void.
Exception | Notes |
---|---|
NetworkError | A network error is triggered on certain combinations of FetchEvent.request.mode and Response.type values, as hinted at in the "global rules" listed above. |
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); }()); });
Specification | Status | Comment |
---|---|---|
Service Workers The definition of 'respondWith()' in that specification. | Working Draft | Initial definition. |
Desktop | ||||||
---|---|---|---|---|---|---|
Chrome | Edge | Firefox | Internet Explorer | Opera | Safari | |
Basic support | 42
|
? | 59
|
No | 29 | No |
Change in behavior when specifying the final URL of a resource. | No | ? | 59 | No | ? | No |
Mobile | |||||||
---|---|---|---|---|---|---|---|
Android webview | Chrome for Android | Edge Mobile | Firefox for Android | Opera for Android | iOS Safari | Samsung Internet | |
Basic support | 42
|
42
|
? | ? | 29 | ? | 4.0 |
Change in behavior when specifying the final URL of a resource. | No | No | ? | ? | ? | No | No |
© 2005–2018 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent/respondWith