Intent to Prototype: Allowing JS web-requesting APIs to modify the User-Agent header

[Andrew Brown]

Contact emails

abro...@gmail.com

Specification

https://fetch.spec.whatwg.org/#forbidden-request-header

Summary

In 2015, the WHATWG Fetch Standard was updated to remove 'User-Agent' from the forbidden header list. For legacy reasons involving CORS implementation, Chromium never took on this update. With this change, JS may now successfully set the 'User-Agent' on a fetch() or XMLHttpRequest() request. Setting the 'User-Agent' via JS will incur a CORS preflight request, as 'User-Agent' is not safelisted. 'User-Agent' header values that come from the browser, Devtools, or Extensions, will not incur CORS preflights. Interactions here may be complex, e.g. if fetch() sets a User-Agent but an extension removes it, the request will still incur a CORS preflight.

Blink component

Blink>Network>FetchAPI

Web Feature ID

fetch

Motivation

Lack of ability to modify the User-Agent hampers some web API interactions (e.g. the Github API asks for users to identify themselves via User-Agent, which is not possible when using fetch() from a Chromium browser: https://docs.github.com/en/rest/using-the-rest-api/getting-started-with-the-rest-api?apiVersion=2022-11-28#user-agent). Additionally, Firefox permits modifying the User-Agent header as-specified, so it is desirable to bring Chromium into parity here.

Initial public proposal

No information provided

Requires code in //chrome?

True (implementation work in CL#5273743 adds some new unit tests to //chrome.)

Tracking bug

https://issues.chromium.org/issues/40450316

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5094781984309248?gate=6191425848999936

This intent message was generated by Chrome Platform Status.