Intent to Ship: Fetch API

159 views
Skip to first unread message

nsm.n...@gmail.com

unread,
Feb 18, 2015, 12:06:40 PM2/18/15
to
Hello,

Target release: FF 38 or 39 (feedback requested)
Currently hidden behind: dom.fetch.enabled.
Bug to enable by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1133861

The Fetch API [1] provides a simpler alternative (the fetch() function) to XMLHttpRequest to fetch resources from the web. At the same time it expresses the underlying platform better by exposing the Request and Response objects.
This API is available on Window and Worker.
Fetch is also a critical part of the ServiceWorker initiative.

According to the spec editor the spec is nearing stabilization. We have had an implementation in the tree for a while that implements most of the spec (see below). While we feel confident in shipping, there are few points of contention where we are looking for clarification before shipping.

1) ESR - FF 38 is an ESR release and shipping a new API with some parts not yet supported may not be the best thing to do. What is the usual policy in such a situation?

2) FormData - N for 38, Y for 39. Patches to add support for FormData in workers and allow FormData to be passed to Request/Response and read back using the formData() method are under review. Blink will be shipping without FormData support, and it is easy to feature detect (by checking for Request.formData) so it is not a risk to ship with this disabled.

3) clone() - Maybe for 38, Y for 39. This will very likely land before 38 branches in which case we will ship it, but it is not in the tree yet. The intention of clone() is to have multiple copies of the body 'stream' available. This is important for ServiceWorkers which often want to cache the data as well as respond to the current request. It is not so useful for window/worker, and we could ship it in 39.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1073231

4) Request.cache - Google has raised some privacy concerns. So I do not intend to enable this yet.
https://github.com/slightlyoff/ServiceWorker/issues/585

5) User prompting for authentication - This is not implemented since the use cases for this are much smaller compared to fetch in general. Instead the 401 response is simply returned as a the result of the fetch, as per spec (Section 4.2, step 4)

Intent to implement: https://groups.google.com/forum/#!searchin/mozilla.dev.platform/implement$20fetch/mozilla.dev.platform/EWGghGeRAV0/2DWWR-KPa_IJ

Support in other engines:
Blink: supports Fetch in ServiceWorkers since 40, and intend to enable it on Window in 42 or 43 - https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/fetch$20api/blink-dev/qwRO52vsQlU/CPLC4G6oG9IJ

IE: Expressed interest on their dashboard
WebKit: No public interest as far as I can tell.

Developer documentation: The MDN team has this on their radar and will have documentation ready by the time this hits release. (high chance of it actually being done in March)

[1]: http://fetch.spec.whatwg.org/

James Graham

unread,
Feb 18, 2015, 12:21:28 PM2/18/15
to dev-pl...@lists.mozilla.org
On 18/02/15 17:06, nsm.n...@gmail.com wrote:

> Support in other engines:
> Blink: supports Fetch in ServiceWorkers since 40, and intend to enable it on Window in 42 or 43 - https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/fetch$20api/blink-dev/qwRO52vsQlU/CPLC4G6oG9IJ

What's the testing story here? I can see some mochitests, bit I wonder
if we have done anything to ensure what we plan to ship is compatible
with what Blink has?

nsm.n...@gmail.com

unread,
Feb 18, 2015, 12:31:43 PM2/18/15
to
We have fairly comprehensive mochitests in dom/workers/tests/fetch and dom/tests/mochitests/fetch. The blink intent to ship email, at the bottom, has a section which documents Canary performing well on our tests. In addition, we pass (except formdata) tests (admittedly not very comprehensive) for this polyfill https://github.com/github/fetch/.

Nikhil

Boris Zbarsky

unread,
Feb 18, 2015, 4:29:31 PM2/18/15
to
On 2/18/15 12:06 PM, nsm.n...@gmail.com wrote:
> 1) ESR - FF 38 is an ESR release and shipping a new API with some parts not yet supported may not be the best thing to do. What is the usual policy in such a situation?

How happy are you backporting security fixes for this code that pop up
over the next year or so to 38?

-Boris

James Graham

unread,
Feb 19, 2015, 11:22:59 AM2/19/15
to dev-pl...@lists.mozilla.org
On 18/02/15 17:31, nsm.n...@gmail.com wrote:

> We have fairly comprehensive mochitests in dom/workers/tests/fetch
> and dom/tests/mochitests/fetch. The blink intent to ship email, at
> the bottom, has a section which documents Canary performing well on
> our tests. In addition, we pass (except formdata) tests (admittedly
> not very comprehensive) for this polyfill
> https://github.com/github/fetch/.


OK. It's good that the Google people managed to run a subset of our
mochitests. It's still disappointing that we are implementing greenfield
web technologies with such an ad-hoc approach to obtaining
interoperability. This seems like a clear case where we could have
written the majority of our tests as web-platform-tests so they could
all — including those requiring non-trivial server side logic — be run
in any browser.

Brian Smith

unread,
Feb 19, 2015, 1:54:25 PM2/19/15
to nsm.n...@gmail.com, dev-platform
<nsm.n...@gmail.com> wrote:
> Target release: FF 38 or 39 (feedback requested)
> Currently hidden behind: dom.fetch.enabled.
> Bug to enable by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1133861

Great work!

Is there a test that verifies that fetch is correctly handled by
nsIContentPolicy (for extensions like AdBlock) and mixed content
blocker? If not, could you please add one before shipping?

Thanks,
Brian

Benjamin Kelly

unread,
Feb 19, 2015, 2:26:25 PM2/19/15
to Boris Zbarsky, dev-pl...@lists.mozilla.org
It seems to me that backporting to dom/fetch should be relatively
straightforward. Its pretty isolated code.

If something needs to be backported for the necko side of the house, then
it probably needs to be fixed in the ESR for XHR and other things anyway.
Whether we ship fetch or not will probably not effect this.

Nikhil, what do you think?

Ben

Boris Zbarsky

unread,
Feb 19, 2015, 4:00:36 PM2/19/15
to
On 2/19/15 2:26 PM, Benjamin Kelly wrote:
> It seems to me that backporting to dom/fetch should be relatively
> straightforward. Its pretty isolated code.

The real question there is how much churn you expect in that code over
the next year as the pieces that aren't one yet end up happening.

> If something needs to be backported for the necko side of the house, then
> it probably needs to be fixed in the ESR for XHR and other things anyway.
> Whether we ship fetch or not will probably not effect this.

Yes, agreed.

-Boris

Benjamin Kelly

unread,
Feb 20, 2015, 11:17:29 AM2/20/15
to James Graham, dev-pl...@lists.mozilla.org
On Thu, Feb 19, 2015 at 11:21 AM, James Graham <ja...@hoppipolla.co.uk>
wrote:
James,

Is there a way to run wpt or th tests with a specific gecko pref enabled?
The initial feedback I received on IRC was "no", unless you want to enable
the pref for all mochitests.

That seems a major issue if we want to encourage new features to use these
tests.

I want to use them in Cache, but I need my feature pref'd off until its
ready as well.

Thanks.

Ben

nsm.n...@gmail.com

unread,
Feb 21, 2015, 7:44:37 PM2/21/15
to
On Thursday, February 19, 2015 at 11:26:25 AM UTC-8, Benjamin Kelly wrote:
> On Wed, Feb 18, 2015 at 4:29 PM, Boris Zbarsky wrote:
>
> >
> >> 1) ESR - FF 38 is an ESR release and shipping a new API with some parts
> >> not yet supported may not be the best thing to do. What is the usual policy
> >> in such a situation?
> >>
> >
> > How happy are you backporting security fixes for this code that pop up
> > over the next year or so to 38?
> >
>
> It seems to me that backporting to dom/fetch should be relatively
> straightforward. Its pretty isolated code.
>
> If something needs to be backported for the necko side of the house, then
> it probably needs to be fixed in the ESR for XHR and other things anyway.
> Whether we ship fetch or not will probably not effect this.
>
> Nikhil, what do you think?
>
> Ben

We do have a CSP type for fetch. Brian, does that automatically handle mixed content?

Ben, are you ok with the clone() that just landed being enabled? If so, I'll flip the pref.

Ben Kelly

unread,
Feb 22, 2015, 9:37:34 AM2/22/15
to nsm.n...@gmail.com, dev-pl...@lists.mozilla.org
> On Feb 21, 2015, at 7:44 PM, nsm.n...@gmail.com wrote:
> Ben, are you ok with the clone() that just landed being enabled? If so, I'll flip the pref.

Clone should be good to go. Thanks!

Ben

nsm.n...@gmail.com

unread,
Mar 9, 2015, 1:06:13 PM3/9/15
to
Removed pref on m-c. This will ship in 39 except for cache mode and authentication prompt.
Reply all
Reply to author
Forward
0 new messages