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

[pfeiffer]

Previously the header for indicating that a resource was preloaded was named VND.PREFETCH. The dot in the header name caused it to be stripped by reverse proxies, including CloudFlare, as discussed in #924

It was discussed that it should be renamed, originally the PR I made in #925 suggested x-purpose. However, it was suggested that the header should instead be named sec-purpose to match a newer spec. This was done in #925 and merged and released as part of v8 beta.

However, it seems that fetch(..) - at least in Chrome - strips this header from the request being made.

To reproduce, fire a manual fetch(..) from the console:

fetch("https://.../", { headers: { "sec-purpose": "preview", "x-something": "foo" })

Inspecting the request headers, the sec-purpose is not sent, while the x-something is:

I guess the sec-... are reserved headers and that fetch strips these out before sending.

I propose that we rename the header to x-purpose which seems to be the header used by Safari and Chrome (for the preview on the launch pages), as well as Facebook in-app browser. I'll wrap up a PR.

[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

[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 👍.

[afcapel]

Fixed in #1108

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