Intent to Ship: Fetch API: Forward reason from AbortController to fetch Response

[Chromestatus]

Contact emails

dead...@google.com

Specification

https://fetch.spec.whatwg.org

Summary

An AbortController can be passed into fetch to allow a request to be aborted; this is already supported see https://chromestatus.com/feature/5631483679080448 When calling abort, you can optionally pass in an "abort reason", and the original fetch promise if it hasn't resolved should be rejected with that reason. This is already working as intended. *However*, if the fetch promise *has* resolved (after reading the header), but the body has not yet been fully read, this is also intended to propagate the abort reason to the Response methods such as Response.blob(), as well as the ReadableStream Response.body. This part is not currently working; the relevant Promises instead are rejected with generic AbortErrors. Firefox at least is compliant here but chromium/Edge/Safari are not.

Blink component

Blink>Network>FetchAPI

Web Feature ID

abortable-fetch

Motivation

No information provided

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: Shipped/Shipping

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No information provided

Debuggability

No information provided

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

Yes

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

Yes
https://wpt.fyi/results/fetch/api/abort/general.any.html Specifically the tests: * response.arrayBuffer() rejects with abort reason if already aborted (and other response methods such as body()) * Stream errors once aborted with abort reason. Underlying connection closed.

Flag name on about://flags

No information provided

Finch feature name

ForwardReasonToFetchBodyAbort

Rollout plan

(RARE) Experiment users ramp up over time

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/502133195

Estimated milestones

Shipping on desktop	153
Shipping on Android	153
Shipping on WebView	153
Shipping on iOS	153

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5158507786665984?gate=6176253840326656

This intent message was generated by Chrome Platform Status.

[Dan Clark]

> Specification

> https://fetch.spec.whatwg.org

Can you please give a more specific link into the part of the spec that defines this behavior?

> WebKit: No signal

Can you request a WebKit signal?

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

> Yes
> https://wpt.fyi/results/fetch/api/abort/general.any.html Specifically the tests: * response.arrayBuffer() rejects with abort reason if already aborted (and other response methods such as body()) * Stream errors once aborted with abort reason. Underlying connection closed.

I'm still unclear on which tests cover this change. Looking at the test results all are already passing in Chrome Stable except for "Readable stream synchronously cancels with AbortError if aborted before reading" which doesn't seem to match this scenario.

> Rollout plan

> (RARE) Experiment users ramp up over time

Can you say more about this roll out plan? This doesn't seem like the kind of thing that would need to be rolled out gradually via experiment.

Lastly please request the other "Prepare to Ship" reviews in the chromestatus entry (Privacy, WP Security, etc).

Thanks,

Dan