Authorization-removal change was compatibility-breaking

[jimrandomh]

Removal of the Authorization header when a request is redirected was proposed in https://github.com/whatwg/fetch/issues/944, merged into the spec in https://github.com/whatwg/fetch/pull/1544, and implemented in nodejs in 18.4.0. This broke my program; see https://github.com/nodejs/node/issues/46287.

I have worked around the problem by switching from nodejs's builtin implementation of fetch to the node-fetch library, which has not implemented this spec change. However, I'm worried that node-fetch is going to make the same change, in which case I'll be forced to pin an obsolete version and accept whatever security issues that creates. As far as I can tell, there is no documented way to handle the case where you have an API key and an endpoint that's going to redirect you. The spec change proposal alludes to an analogous curl behavior, which curl disables with --location-trusted, but there is nothing analogous to --location-trusted in the fetch specification or the documentation of any of its implementations.

[annevk]

In non-server environments you could not rely on this behavior so there it is not considered a breaking change. I could imagine offering an option to preserve the header though, even when there's a cross-origin redirect.

Thought --location-trusted might imply that it's only preserved for a single hop? That sounds a bit iffy given that we try to treat redirects identical.

(Though presumably on servers there is a workaround here by using redirect mode "manual" as they won't have to hide the response.)

[jimrandomh]

As far as I can tell https://github.com/whatwg/fetch/issues/763 still applies and so redirect mode "manual" isn't helpful here.

[annevk]

Why does it apply to servers? Reportedly server implementations of fetch can read cookies as well, so why would they hide redirects?

[jimrandomh]

I don't know why nodejs hides the destination URL from redirects, but I tested 18.15.0 and empirically it does. My guess is that they implemented parts of the spec that were intended for browsers, and didn't consider it carefully enough to notice the functionality-hole this created.

[oliverdunk]

An interesting issue was raised in the Web Extensions Community Group by a developer impacted by this change: https://github.com/w3c/webextensions/issues/502

In their case, they have an extension which redirects an API endpoint to a local server, to make development easier. They don't want users to have to configure API credentials in their extension if the request already has them but need credentials from a request to be passed along to the local server. Since extensions are moving towards the declarativeNetRequest API, which is fully declarative, they can't run any logic which could access the credentials before redirecting and really need the browser to handle this.

I could imagine offering an option to preserve the header though, even when there's a cross-origin redirect.

If this was an option I imagine it would be sufficient, since the extension could wrap any fetch requests and make sure they set the parameter (extensions are already in a privileged space and can run scripts on the page). A few other options that come to mind:

• Could there be a default exception for requests to localhost?
• We could add/make changes to an extension API. This is unlikely to be a priority unless this situation comes up more though, so it'd be nice to solve on the web if possible.

Happy to chat more if there's interest. I wanted to pass on the feedback since I found it interesting.