fetchEvent.type = "navigate" is confusing

[jakearchibald]

Feels like both "type" and "fetch" are wrong here.

Maybe "type" should be "origin", and "fetch" is "resource"?

So:

this.onfetch = function(event) {
  if (event.origin == 'resource') {
    // ...
  }
}

[annevk]

Isn't the type of event a "fetch"? The type is always the name of the event being dispatched.

[annevk]

And origin should really never be anything but the scheme/host/port tuple.

[jakearchibald]

@annevk: Right, type should always be "fetch", that's why the current API is confusing. It currently uses type to differentiate between fetched that resulted from navigations.

See your point about "origin". Any better ideas?

[annevk]

I thought the idea with navigate was that navigate causes a fetch but you can decide to handle it all from the navigate event? (If we ever do that...)

[jakearchibald]

The navigate event might be implemented later, but you want to know in the fetch event if the fetch was caused by a navigate.

The use case is serving a helpful "You're offline and that page isn't available" page when the user navigates, but not on xhr etc. Also, could be used if the user navigates to an RSS feed, you could use it to display a page explaining how RSS should be used.

[jakearchibald]

Could even be a fetchEvent.fromNavigate boolean

[annevk]

Maybe source or some such? I think we want to expose CSP types somewhere. E.g. img-src, script-src etc. This could fit into that.

[annevk]

Although that would really be part of the Request object.

[jakearchibald]

Happy with request.source.

[jakearchibald]

http://developer.chrome.com/extensions/webRequest.html#type-RequestFilter defines "main_frame", "sub_frame", "stylesheet", "script", "image", "object", "xmlhttprequest", or "other". The naming is a little off (ew, underscores), but that kind of granularity could be useful.

[annevk]

I think we want to copy from CSP. Maybe not the names. There's sniffing context too which might be useful. The people in charge of networking would be good to help out here to know exactly what what is right.

[slightlyoff]

Decisions from today's discussion:

• type -> purpose
• values for purpose are derived from CSP: connect, font, img, media, object, script, style, worker, popup, child, navigate
• All of these types are exclusive
• connect defines XHR, fetch, and other unspecified loads
• popup, child, and navigate replace e.type and e.isTopLevel

Needs review from the CSP folks; /cc @abarth @mikewest

[devd]

Just as a contrast to the Chrome documentation: here's mozilla's nsiContentPolicy: https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIContentPolicy It defines a lot of possible request types.

I am not sure about using CSP. CSP does not aim to look at network requests: rather, it is about what content gets into the page. There are requests that CSP does not talk about (anchor, anchor ping, sendBeacon) and there are requests that CSP does talk that SW does not (form-action, as opposed to the broader "navigation" that SW talks about)

[annevk]

We want to expose the superset. While CSP is applied between the document and the service worker (in the fetch layer), passing through where the response will be used can be useful in deciding certain things. E.g. whether to be strict about content-type, what to do about fallback, etc.

[sicking]

We also need to clarify if the fetch that happens when a (non-serviceworker) worker is being loaded. Does the fetch that happens to load the worker have .topLevel set to true? Is it considered a navigation? At the very least we should make it clear that it's a fetch of a main worker-script.

[annevk]

.purpose will return "worker" for that scenario.

[annevk]

See also http://wiki.whatwg.org/wiki/Contexts "context" seems like a name we could use here too rather than "purpose".

[annevk]

This is done.