Intent to Ship: Fetch API (global scope)

[Kenji Baheux]

Contact emails

Engineering: yhi...@chromium.org, tyos...@chromium.org, ho...@chromium.org

PM: kenji...@chromium.org

Spec

https://fetch.spec.whatwg.org/#fetch-api

Summary

The Fetch API is a new API for loading resources in web applications and is intended to supersede XMLHttpRequest. Fetch API is already available in ServiceWorker scope. This Intent to Ship is for exposing it on window and (shared)worker scopes.

Advantages over XHR:

• Promises based async operations

• finer level of control

• upcoming integrations with other APIs. For instance, in a follow-up Intent to Ship, an integration with the Streams API [1] will improve the state of progressive processing of data: no need to poll as you would with XHR and it will let you stream Binary content too.

    API level detail (includes known caveats)

Link to “Intent to Implement” blink-dev discussion

N/A. (Fetch API was implemented as a part of ServiceWorker)

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

Prerequisite: Chrome Canary with chrome://flags/#enable-experimental-web-platform-features enabled

http://addyosmani.com/demos/fetch-api/

Debuggability

On par with XMLHttpRequest.

Compatibility Risk: pluses and minuses

+ There is a WHATWG spec for the Fetch API.

+ Mozilla is implementing this API (available in nightly behind dom.fetch.enabled; issue tracker).

+ Fetch API has already shipped in M40 (in Service Worker)

+ No additional surface exposed for the Fetch API

+ Data indicates that exposing fetch in the global scope is safe (e.g. collisions with id=fetch)

+ Canary is doing great on Mozilla’s tests for Fetch API in window:

  = actual failures are on aspects we don’t support yet (e.g. schemes such as about, data, blob)

  + a few false positives caused by this implementation bug in Firefox

  - a few Firefox specific tests that are hard to get running (e.g. test_headers.html relies on internal APIs, some no cors tests relying on a non-public test server)

- some side issues got in the way of running our Fetch API tests against Firefox’s implementation (e.g. missing ES6 features, not yet implemented Fetch API key features for our tests).

Tracking bug

crbug.com/436770

Link to entry on the feature dashboard

https://www.chromestatus.com/features/6730533392351232

[1] https://streams.spec.whatwg.org/

[Anne van Kesteren]

On Fri, Jan 30, 2015 at 8:13 AM, Kenji Baheux <kenji...@chromium.org> wrote:
> Compatibility Risk: pluses and minuses

As I understand it you are planning on shipping a subset and even
disable certain functionality. Could you discuss that here perhaps?


--
https://annevankesteren.nl/

[Takeshi Yoshino]

It's explained in this attached slides. Here's the summary.

fetch()

- ignores Request.cache

-- Reason: Needs to resolve privacy leak concern. See this issue

- fails (rejects the returned Promise with a TypeError) if Request.mode is no-cors

-- Reason: Needs to resolve security concern. See this issue

Request

- context is just not implemented yet

Response

- the following items are just not implemented yet

-- formData()

-- error()

-- redirect()

-- finalURL

-- ok

[Anne van Kesteren]

On Fri, Jan 30, 2015 at 11:20 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:
> fetch()
> - ignores Request.cache
> -- Reason: Needs to resolve privacy leak concern. See this issue

Feedback welcome by the way. mnot suggested the risk is about the same
with timing attacks.

> - fails (rejects the returned Promise with a TypeError) if Request.mode is
> no-cors
> -- Reason: Needs to resolve security concern. See this issue

Given that you are shipping this in service workers your decision here
seems extremely awkward and I don't really understand it.


--
https://annevankesteren.nl/

[Chris Harrelson]

Hi Kenji,

Could you give more details on the data showing why this change to the global scope is web compatible?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Kenji Baheux]

Hi Chris,

On Sat, Jan 31, 2015 at 3:18 AM, Chris Harrelson <chri...@chromium.org> wrote:

Could you give more details on the data showing why this change to the global scope is web compatible?

We ran a couple of queries against the index (e.g. checking for usage of id=fetch) and the numbers we got were insignificantly low.

 

On Fri Jan 30 2015 at 2:27:20 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Fri, Jan 30, 2015 at 11:20 AM, Takeshi Yoshino <tyos...@chromium.org> wrote:
> fetch()
> - ignores Request.cache
> -- Reason: Needs to resolve privacy leak concern. See this issue

Feedback welcome by the way. mnot suggested the risk is about the same
with timing attacks.

IIRC, one more practical reasons is that we haven't got around implementing it.

However, it seems quite useful so let me circle back with our privacy team so we can target M43~. 

[Kenji Baheux]

> - fails (rejects the returned Promise with a TypeError) if Request.mode is
> no-cors
> -- Reason: Needs to resolve security concern. See this issue

Given that you are shipping this in service workers your decision here
seems extremely awkward and I don't really understand it.

Our original concern is described in the issue that Takeshi linked to.

After further discussion, the actual concern evolved into gaining knowledge about the state of a server for a given user via fetch. We've confirmed that the spec and our implementation doesn't allow for this.

Given that, we could allow no-cors but, IINM, it would be useless without the Cache API (global scope).

 

--
https://annevankesteren.nl/

[Anne van Kesteren]

On Mon, Feb 2, 2015 at 1:41 PM, Kenji Baheux <kenji...@chromium.org> wrote:
> Given that, we could allow no-cors but, IINM, it would be useless without
> the Cache API (global scope).

That is fair. More uses for it are envisioned down the line, but at
this point it would indeed mostly be for testing purposes if you don't
have the cache API.


--
https://annevankesteren.nl/

[Chris Harrelson]

LGTM

[Jake Archibald]

"our app has its own 'fetch' and I assume it'll break when fetch lands" - https://twitter.com/plestik/status/562240598552612865

Although our index checks don't suggest this is going to be an issue, do we have anything set up to measure errors that are created by this? Is window.fetch overwritable?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jake Archibald]

I guess I should have just checked. window.fetch is indeed overwritable. That feels sensible to me. Anne, is that spec compliant?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Philip Jägenstedt]

The IDL for the fetch() method is pretty normal-looking and doesn't use [Unforgeable], so a page-defined window.fetch will simply shadow it. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3402 shows that it works in the case of alert().

LGTM2

Philip

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Takeshi Yoshino]

Right. Like other APIs, fetch() would just be overwritable.

We found some sites which have code checking whether fetch() is defined on window or not, and use it if it's available. They seem that just waiting for window.fetch() and using Polyfill until then. So, no problem.

Takeshi

[Dimitri Glazkov]

LGTM3.

[Jochen Eisinger]

lgtm

it does not affect this intent, but once we move towards shipping no-cors, we should discuss whether this is a feature that will require a secure context or not

best

-jochen

On Tue Feb 03 2015 at 6:28:29 PM Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM3.

[Philip Rogers]

LGTM4. I think this is the right direction for a consistent web platform.