Intent to Implement and Ship: Fetch API Cancellation (AbortController and AbortSignal)

[Adam Rice]

Contact emails

ri...@chromium.org, tyos...@chromium.org, yhi...@chromium.org

Design doc/Spec

Spec: https://fetch.spec.whatwg.org/#ref-for-dom-request-signal

Design doc: https://docs.google.com/document/d/1OuoCG2uiijbAwbCw9jaS7tHEO0LBO_4gMNio1ox0qlY/edit

Summary

A fetch() can be made cancellable by passing an AbortSignal "signal" in the fetch options. Calling abort() on the associated AbortController will then cancel the fetch.

Motivation

Cancellation has been available in XMLHttpRequest for a long time, but not in the Fetch API. Although the caller of fetch() can disregard the result, the fetch will still proceed to completion, wasting bandwidth and battery and causing additional latency. Applications for which cancellation is critical have been blocked from migrating to the Fetch API due to the absence of this feature.

Risks

Interoperability and Compatibility

Low risk. Standardised, shipping in two major browsers, has existing web platform tests.

Edge: Shipped

Firefox: Shipped

Safari: No signals

Web developers: Huge demand for the feature. There was a long debate over how the feature should be exposed to the web platform, but this API now appears to have consensus.

The issue for the feature on Chromium's bug tracker has gained 41 stars in 5 months.

Long and very engaged standards discussion: https://github.com/whatwg/fetch/issues/27 (328 comments) and https://github.com/whatwg/fetch/issues/447 (230 comments).

Discussion on StackOverflow: https://stackoverflow.com/questions/31061838/how-do-i-cancel-an-http-fetch-request/47250621#47250621

Tests are at https://github.com/w3c/web-platform-tests/tree/master/dom/abort for AbortSignal and AbortController in isolation, and https://github.com/w3c/web-platform-tests/tree/master/fetch/api/abort for the integration with the Fetch API.

Ergonomics

AbortController and AbortSignal are expected to be used with Streams and Web Locks in future.

No performance impact (cancellation is a fundamental feature of the underlying APIs).

Activation

There is a simple stub polyfill at https://github.com/mo/abortcontroller-polyfill that allows the API to be used in browsers that do not support it natively. Once Chrome ships this feature it will be in the majority of evergreen browsers. The feature is very easy to use and to add incrementally to existing applications.

Debuggability

Cancelled requests are already shown in DevTools network tab.

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

Yes.

Is this feature fully tested by web-platform-tests?

Tests are at https://github.com/w3c/web-platform-tests/tree/master/dom/abort for AbortSignal and AbortController in isolation, and https://github.com/w3c/web-platform-tests/tree/master/fetch/api/abort for the integration with the Fetch API.

A few testing gaps have been identified and are noted in the design doc. They will be addressed during the implementation.

Link to entry on the feature dashboard

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

Requesting approval to ship?

Yes

[Jake Archibald]

Developer-facing documentation: https://developers.google.com/web/updates/2017/09/abortable-fetch

Also, tests for interaction with service workers: https://github.com/w3c/web-platform-tests/pull/7674 (not yet merged, but should be useful).

Does this intent include service worker integration?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxOKt1zzyQh3-R0_7142XwntmnoFqMioEF%2B2B4N%3Dcj43Q%40mail.gmail.com.

[Ben Kelly]

Just FYI, I believe there is a small gap in the WPT coverage you might want to be aware of.  Basically:

1. Window does a fetch() with an abort controller signal set

2. ServiceWorker intercepts with a FetchEvent

3. Calling abort() on the window abort controller should abort the FetchEvent.request.signal

We have a test written, but it seems we did not upstream it because we had problems with our implementation.  See this bug:

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

I can try to to see if that can be landed now.

Also, I believe interactions between abort and Cache API are not tested currently.  For example, we could have a test that does Cache.add(request), request gets intercepted by a SW to pause it, abort the request, and verify Cache API correctly stores nothing.

Anyway, this is mostly just an FYI so you are aware of these corner cases and lack of coverage.  Great to see this work starting in chromium.

Thanks.

Ben

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

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

[Domenic Denicola]

Perhaps this would be a good time to figure out the answer to the spec question at https://github.com/whatwg/dom/issues/493 , either in favor of a change or coming down against it? I don’t think this will be a compatibility issue as in practice the change should affect very few cases, but the sooner we figure it out, the less likely we are to have any compat issues.

 

--

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdxOKt1zzyQh3-R0_7142XwntmnoFqMioEF%2B2B4N%3Dcj43Q%40mail.gmail.com.

 

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2B1UsbQcw3WcJW1P8gqoS%3DbQn8zQd5vZEhYjXeEKSbd9wDDpMg%40mail.gmail.com.

[Adam Rice]

[Adam Rice]

Resent from @chromium.org address. Please disregard this one.

[Adam Rice]

On 19 December 2017 at 23:30, Jake Archibald <jakear...@chromium.org> wrote:

Does this intent include service worker integration?

Sorry, no. To be honest, I wasn't aware of the impact on service workers. I have added a note about this to the "Followup work" section of the design doc. 

[Jochen Eisinger]

+adamk & mkwst fyi

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdy769u4ikyyUgMQ75Wr7EBZu03T2SnChYaKaJ7z0Nrhdw%40mail.gmail.com.

[Mike West]

There's a lot of demand for this, and I'm happy to see that y'all were able to drive things to a consensus folks could agree upon. :) The risk here seems quite low, given that other vendors have already implemented and that we have agreed-upon layout tests. The outstanding issue Domenic points to seems both minor and like something that can be reasonably dealt with during implementation. The SW interaction likewise seems like something where the "right answer" is clear, so I'm not worried about interop there. LGTM1.

-mike

[Daniel Bratell]

LGTM2

/Daniel

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DdoBNSOTdXqnuJ%2BVvxCWTC%2BmJALE2gY_HMU4kcc%2B6N7tg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.zbjr02vhrbppqq%40cicero2.linkoping.osa.