v8.0.0-beta1: Preloader: `Sec-Purpose` header is ignored by `fetch(..)`

[pfeiffer]

v8.0.0-beta1: Preloader: `Sec-Purpose` header is ignored by `fetch(..)`

[pfeiffer]

As discussed in #1101 the Sec- prefixed headers are intentionally not allowed to be set via fetch(..):

In the Fetch Standard under the "Forbidden Header Name" section, the following paragraph explicitly mentions that any header starting with Sec- should not be allowed to be set by client (eg. via JS), but rather be fully controlled by the user agent:

A header (name, value) is forbidden request-header if these steps return true:
...

• If name when byte-lowercased starts with proxy- or sec-, then return true.

The linked spec also mentions why these are reserved, even in the future:

Note: These are forbidden so the user agent remains in full control over them.
Header names starting with Sec- are reserved to allow new headers to be minted that are safe from APIs using fetch that allow control over headers by developers, such as XMLHttpRequest. [XHR]

The current implementation in Turbo 8 is a no-op.

Ping @davidalejandroaguilar

[afcapel]

Fixed in #1108

We're now using X-Sec-Purpose instead.

[psyipm]

It would be great to have this addressed. Could you guys please have a look?

Ping @rik @hey-leon @seanpdoyle @davidalejandroaguilar @afcapel

[hey-leon]

Hey @psyipm I am not part of any team on the Turbo repository but I did read the PR body and elaborating comment and it seems pretty clear cut to me. If its explicitly called out that Sec-* is not allowed in the whatwg specifications for fetch it would make sense to change it 👍.