Serviceworker: Create F2F agenda - 7 November 2017

Created on 11 Oct 2017  Â·  16Comments  Â·  Source: w3c/ServiceWorker

Location

TPAC, Burlingame.

Agenda

Push API

I don't know the details, but I believe the Safari folks have some concerns around the push API, so let's go through that first, timeboxed to an hour.

Changes & bugs

Interesting feature requests

All 16 comments

Client API and Navigate-hook

The latest agreement on FetchEvent (https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-311023682):

  • clientId: The client that initiates the request.
  • resultingClientId: The potentially-reserved client that will house the resulting document/worker.
  • replacesClientId: an existing client that will be replaced, or have its document replaced https://github.com/w3c/ServiceWorker/issues/1091#issuecomment-311325493

Proposal of not exposing reserved clients: #1216.

We are here now. I'd like to discuss:

  • If the above meets the original use cases?

    • Per-client cache control.

    • Messaging to reserved clients: this will be excluded by #1091.

  • Will devs be happy?
  • Implementable?
  • How to write spec?

Issues:

  • Client Id attributes and the initial about:blank case: #1091.
  • Not exposing reserved clients (#1216) may resolve #1034, #1035, #1215.
  • Navigate-hook: #765.
  • Redirected navigation: #1031.
  • Spec details: #1042.
  • Resolved (not closed yet): #1080, #1090.

@jungkees cheers! I've added the stuff I've been looking at so far to the OP. I'll merge yours into that.

I'm sweeping through open issues today.

We're trying to implement https://github.com/whatwg/fetch/pull/146 and ran into a potentially thorny spec issue in https://github.com/whatwg/fetch/pull/146#issuecomment-341710548. Might be worth talking about in person.

How do people feel about discussing “meaningless” Accept headers like */* for images in Firefox that make dealing with such requests in Service Workers hard and encourage relying on file extensions, especially as there is no consistency among how browsers deal with this.

How do people feel about discussing “meaningless” Accept headers like / for images in Firefox that make dealing with such requests in Service Workers hard and encourage relying on file extensions, especially as there is no consistency among how browsers deal with this.

We can discuss it, but standardizing Accept headers is a bit orthogonal to service workers. I recommend raising a fetch spec issue to investigate alignment between browsers on Accept headers.

While it applies to Ajax situations like fetch and XMLHttpRequest, the issue applies to all other static “fetching” scenarios as well, be it link, img, a, etc. Dealing with it in the context of the Fetch API alone seems too limited, at least from my point of view.

@tomayac the fetch spec deals with all browser fetching, not just the fetch API.

I've moved the push API stuff to the morning, so @beverloo can join.

All spec'd browser networking loading goes through the fetch specification (modulo old specs not updated yet). Not just the fetch() API.

Thanks both for the clarification. I guess fetch spec issue(s) is the way to go then.

Planning to start around 09:00 tomorrow.

Sorry to miss this F2F. Have a really nice and productive session!

@wanderview points out that we would benefit from better tests for the cache API.

Action: Add notes about cache sizes + opaque responses. But diversity in mitigation is welcome.

Action: Built a test that creates a same-origin worker, but in the service worker fetch a response from another origin. According to the spec it should work, and the base url should be the response url. If it fails, @wanderview would be interested in adding that failing to the spec.

Was this page helpful?
0 / 5 - 0 ratings