.NET 7.0: HttpClient not sending DefaultRequestHeaders when executing a 301 redirect

I'm puzzled at seeing how a HttpClient instance is not sending DefaultRequestHeaders (specifically the Authorization header) when following a 301 redirect. Considering the name of the collection (i.e., DefaultRequestHeaders) I would expect these to be always sent. Is this a bug or a behavior to be expected?

To provide a bit more context to the failure I'm facing, I'm trying to call the Microsoft Graph getOffice365GroupsActivityDetail API and starting yesterday this API is forcing with a 301 http response code a redirect to location https://reportsweu.office.com/graph/v1.0/data/[tenant-id]/Microsoft.O365Reporting.getOffice365GroupsActivityDetail and the unexpected thing is that a different token seems to be required since making a call with the bearer token valid for calling the original API (i.e. https://graph.microsoft.com/v1.0/reports/getOffice365GroupsActivityDetail) fails with a "S2S auth failed" error.

I just now discovered that this behavior is by design as the documentation on HttpClientHandler.AllowAutoRedirect Property states:

> The Authorization header is cleared on auto-redirects and the handler
> automatically tries to re-authenticate to the redirected location. No
> other headers are cleared. In practice, this means that an application
> can't put custom authentication information into the Authorization
> header if it is possible to encounter redirection. Instead, the
> application must implement and register a custom authentication
> module.

To me this behavior is not intuitive as after the 301 redirect the HttpClient still shows the header as present in the DefaultRequestHeaders collection and yet it will not be sent when the redirect is followed. At this point it's probably better to add this header to the Headers collection on the HttpRequestMessage object other than to the DefaultRequestHeaders collection on the HttpClient object as this allows greater control over adding it or not to the new HttpRequestMessage object required for following the redirect.

That's no bug at all. It's actually a common security measure against authentication leaks. Just like other tools, if you want to retain the header you'll have to do it explicitly.

This measure is used to prevent credential leaks. Without this, a hacked site could redirect you to a malicious 3rd party site, record the credentials in the Authorization header and then redirect you back to the final site.

.NET Framework works this way as well. There was a bug in .NET Core 2.0 (Not Stripping Auth in HttpClientHandler redirects by default) that didn't reset the Authorization header but that was fixed in 2.1

Other tools work the same way too, including curl. In CVE-2018-1000007 for example, they describe exactly this scenario:

> When asked to send custom headers in its HTTP requests, curl will send that set of headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value.

> Sending the same set of headers to subsequent hosts is in particular a problem for applications that pass on custom Authorization: headers, as this header often contains privacy sensitive information or data that could allow others to impersonate the curl-using client's request.

The solution was to reset the header unless the user explicitly forces the tool to reuse it :

> custom Authorization: headers will be limited the same way other such headers is controlled within curl: they will only be sent to the host used in the original URL unless curl is told that it is ok to pass on to others using the CURLOPT_UNRESTRICTED_AUTH option.