In Google Chrome console next to the status code of HTTP Request
we have info (from ServiceWorker)
.
Can Request
be aware somehow that the Response
came from ServiceWorker? Comparing date
from Response Headers
maybe?

- 81,827
- 26
- 193
- 197

- 2,070
- 1
- 18
- 30
1 Answers
By design, a response returned via a FetchEvent#respondWith()
is meant to be indistinguishable from a response that had no service worker involvement. This applies regardless of whether the response we're talking about is obtained via XMLHttpRequest
, window.fetch()
, or setting the src=
attribute on some element.
If it's important to you to distinguish which responses originated via service worker involvement, the cleanest way I could think of would be to explicitly add an HTTP header to the Response
object that is fed into FetchEvent#respondWith()
. You can then check for that header from the controlled page.
However, depending on how your service worker is obtaining its Response
, that might be kind of tricky/hacky, and I can't say that I recommend it unless you have a strong use case. Here's what an (again, not recommending) approach might look like:
event.respondWith(
return fetch(event.request).then(function(response) {
if (response.type === 'opaque') {
return response;
}
var headersCopy = new Headers(response.headers);
headersCopy.set('X-Service-Worker', 'true');
return response.arrayBuffer().then(function(buffer) {
return new Response(buffer, {
status: response.status,
statusText: response.statusText,
headers: headersCopy
});
});
})
)
If you get back an opaque Response
, you can't do much with it other than return it directly to the page. Otherwise, it will copy a bunch of things over into a new Response
that has a an X-Service-Worker
header set to true
. (This is a roundabout way of working around the fact that you can't directly modify the headers
of the Response
returned by fetch()
.)

- 53,580
- 14
- 141
- 167
-
Thanks, Jeff. That question is a result of your [previous answer](http://stackoverflow.com/questions/29843547/storing-rest-requests-with-service-workers-to-sync-them/29922616#29922616), where you pointed to _Make sure your users are aware that their HTTP POST is being queued_. What's best practice to make user (application) aware of that? I thought that additional header would be a good option, as ServiceWorkers are the proxy and are handling the whole fetch/cache/respond operation. Therefore application itself has no other option to be aware of being offline. – Karol Klepacki May 06 '15 at 07:32
-
2I'd say that you should replay the requests from the controlled page, not the service worker, in order to ask permission/notify the user about it. If you queue them in IDB, then you can easily load those in via the controlled page. If you queue them using the Cache Storage API, you can load them in using `window.caches` in Chrome 43+. Since your controlled page knows that it's a replay request, you don't need the service worker to add in a special header or anything like that. – Jeff Posnick May 06 '15 at 14:47
-
Don't you think that it's anti-pattern? In modern software development we want to have layers for specific part of code, and considering SW as a [programmable network proxy](http://www.html5rocks.com/en/tutorials/service-worker/introduction/), our application should care only to send a request, and SW should perform all actions needed to make it work. And it has some unique means to do that like Background Sync. I think we should continue this discussion at Alex's GitHub. – Karol Klepacki May 07 '15 at 07:30
-
2Replaying "in the background" with only SW involvement makes sense for things like Analytics pings. But we just added replays of offline My Schedule changes to https://events.google.com/io2015/, and I can say from experience that we had no choice but to initiate it from the controlled page. Only the controlled page has access to fresh OAuth 2 tokens.Initiating the replays from the controlled page also makes it easier to notify the user when they're complete without having to add in the "hacky" header. – Jeff Posnick May 07 '15 at 14:58
-
Very helpful answer (as usual) @JeffPosnick. A question: when you create the new `Response`, you copy the `status` and `statusText` properties from `response`. Should you also be copying other properties like `ok`, `type` and `url`? (i.e. those stated here: https://developer.mozilla.org/en-US/docs/Web/API/Response#Properties) – drmrbrewer Nov 03 '17 at 11:26