[ServiceWorker] Can we replace event.default() with something less magic? (#607)

```js
self.addEventListener(event => {
  event.respondWith(fetch(event.request));
});
```

The above is close to default browser behaviour (from the document's perspective), with the exception that `fetch()` processes redirects, so as far the document is concerned, it gets a response for the original request url. This will have an impact on resources that treat their final request url as the base url, such as pages, workers & CSS.

As a solution, we invented `event.default()`:

```js
self.addEventListener(event => {
  event.respondWith(event.default());
});
```

`event.default()` resolves with the final response, but the document is knows about the changes request goes through to make it, so it knows the final request url.

This is problematic because:

* The current spec requires the original fetch to call SW, then `event.default()` drops back into the original fetch, but then goes back to the SW to resolve `event.default()`, then back down to fetch with the actual final resolving value (see https://www.w3.org/Bugs/Public/show_bug.cgi?id=27524)
* The resolved value from `event.default()` isn't particularly useful for caching purposes. You have no access to the final request url, so you can only cache it against the original request url, so you're going to break base urls if you later use it from the cache

Note: Breaking base urls isn't always bad. If you're serving a page shell you want the base url to be the original request url, not the url of the page shell.

Note: Exposing redirects is a security no-go, as some sites use them to pass tokens around. Could this be replaced by a flag on the response indicating that fetch should update the request url with the response url?

```js
event.respondWith(
  fetch(event.request).then(response => {
    response.redirectToFinalURL = true;
    return response;
  })
);
```

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/607

Received on Tuesday, 20 January 2015 15:06:21 UTC