Re: [w3c/ServiceWorker] Making a concurrent request for navigations (#920)

Some thoughts from #whatwg IRC today:

In regards to the "preload header", it feels like we are close to a somewhat generic thing that could be separated from the service worker API.  Perhaps we could consider:

1. An API that matches Request objects using the Cache API matching algorithm.
2. Stores Headers values.
3. When an origin performs a fetch it matches the Request and appends any resulting Headers
4. A service worker preload fetch would always have a `ServiceWorkerPreload` header.  This would let Requests use a `Vary:ServiceWorkerPreload` header to restrict things to preloads.

Then you could do things like:

```
let headers = new Headers();
headers.append('X-Food', 'Candy Corn');
headers.append('X-Drink', 'Cider');

let request = new Request('/order.html');

autoHeaders.put(request, headers);
```

Or for a preload only header:

```

let headers = new Headers();
headers.append('X-Preload-Value', 'Boo');

let request = new Request('/order.html', {
  // spec service worker preload requests to include 'ServiceWorkerPreload' header
  headers: { Vary: 'ServiceWorkerPreload' }
});

autoHeaders.put(request, headers);
```

Note, this does not provide any substring matching.  So it doesn't allow you to set headers for an entire scope or collection of URLs.  If that is needed we could consider adding it.  For Cache API, though, we considered it a de-opt and removed it previously.  Maybe its more necessary for something like this, though.

Anyway, this is just an idea.  I'm not objecting to the current spec proposal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/920#issuecomment-252949482