New Headers added in ocelot using DownstreamScheme Http doesn't arrive to the downstream service. For Https they arrive.

[siualpinto]

Hi
I need to change the access token of requests that go to the APIs via the Ocelot API Gateway.
I try to use a DelegatingHandler or PreQueryStringBuilderMiddleware/PreAuthorizationMiddleware, and the behaviour is the same.
Both change the Header in the request, but when I receive the request in the API, it seems that it uses all the original Headers. None of the new headers that I add reach the API.
Even tried to use it via configuration using the DownstreamHeaderTransform or UpstreamHeaderTransform in the route, but nothing.

Middleware

TokenResult tokenResult = ...;
 DownstreamRequest downstreamRequest = httpContext.Items.DownstreamRequest();
 httpContext.Request.Headers.Authorization = tokenResult.AccessToken;
// or 
 downstreamRequest.Headers.TryAddWithoutValidation("Authorization", $"Bearer {tokenResult.AccessToken}");

 _logger.LogInformation($"New Token: {httpContext.Request.Headers.Authorization}");

Delegating handler

TokenResult tokenResult = ...;
request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", tokenResult.AccessToken);

Is there some configuration that I'm missing to enable the injection of Headers?

[raman-m]

Hi
Show all code!
Upload complete solution for review: Program.cs, ocelot.json, and all C# classes.
Why do you sniff the token which was not generated on Ocelot's side?
If token was generated by downstream endpoint then the token must be forwarded to downstream without any changes via anonymous route (no AuthenticationOptions at all).

[siualpinto]

The flow is: App (Keycloak token) -> Ocelot API Gateway -> Authorization API (Generate new Token and return to Ocelot) -> Update Token in Ocelot API Gateway -> API

Ocelot.json = https://pastebin.com/pWpEsWMj you can follow the "Sample" API
Program Services IoC = https://pastebin.com/h7rkX8AG

Delegating Handler:

namespace ApiGateway
{
    public class MyReplaceTokenAuthorizationDelegatingHandler : DelegatingHandler
    {
        private readonly IScopeFactory _scopeFactory;
        private readonly IAuthorizationApiClientFactory _authorizationApiClientFactory;
        private readonly ILogger<MyReplaceTokenAuthorizationDelegatingHandler> _logger;
        private readonly IHttpContextAccessor _httpContextAccessor;
        private const string REDIRECT_TO_AUTHORIZATION_API_CLAIM_TYPE =
            "redirectToAuthorizationApi";

        public MyReplaceTokenAuthorizationDelegatingHandler(
            IScopeFactory scopeFactory,
            IAuthorizationApiClientFactory authorizationApiClientFactory,
            ILogger<MyReplaceTokenAuthorizationDelegatingHandler> logger,
            IHttpContextAccessor httpContextAccessor)
        {
            _scopeFactory = scopeFactory;
            _authorizationApiClientFactory = authorizationApiClientFactory;
            _logger = logger;
            _httpContextAccessor = httpContextAccessor;
        }

        protected override async Task<HttpResponseMessage> SendAsync(
           HttpRequestMessage request,
           CancellationToken cancellationToken)
        {

            try
            {
                _logger.LogInformation($"Check if is to redirect to Authorization API");
                _logger.LogInformation($"Claims {_httpContextAccessor.HttpContext.User.Claims.Count()}: " +
                    $"{string.Join(',', _httpContextAccessor.HttpContext!.User.Claims.Select(c => c.ToString()))}");
                if (IsToRedirectAuthorization(_httpContextAccessor.HttpContext))
                {
                    _logger.LogInformation($"Redirect to Authorization API");
                    await RedirectToAuthorizationApiAndUpdateTokenHeaderAsync(request);
                    _logger.LogInformation($"Success to redirect to Authorization API");
                }
            }
            catch (Exception exc)
            {
                _logger.LogException(exc);
                throw;
            }
            return await base.SendAsync(request, cancellationToken);
        }

        private bool IsToRedirectAuthorization(HttpContext httpContext)
        {
            IEnumerable<Claim> claims = httpContext!.User.Claims;
            string? redirectClaimString = 
                GetStringValueFromClaimOrDefault(claims, REDIRECT_TO_AUTHORIZATION_API_CLAIM_TYPE);
            _ = bool.TryParse(redirectClaimString, out bool redirect);
            return redirect;
        }

        private string? GetStringValueFromClaimOrDefault(IEnumerable<Claim> claims, string claimType)
        {
            Claim? claim = claims.FirstOrDefault(x => x.Type.Equals(claimType));
            string? value = null;
            if (DoesClaimExist(claim))
            {
                value = claim!.Value;
            }
            return value;
        }

        private bool DoesClaimExist(Claim? claim)
        {
            return claim != null && !string.IsNullOrWhiteSpace(claim.Value);
        }
        private async Task RedirectToAuthorizationApiAndUpdateTokenHeaderAsync(HttpRequestMessage request)
        {
            AuthenticationHeaderValue authHeaderValue = request.Headers.Authorization!;
            string? originalToken = authHeaderValue.Parameter;
            if (!string.IsNullOrWhiteSpace(originalToken))
            {
                using (IDisposable scope = _scopeFactory.Create())
                {
                    IAuthorizationApiClient authorizationApiClient = _authorizationApiClientFactory.CreateScoped(scope);
                    TokenResult tokenResult = await authorizationApiClient.Tokens.GenerateTokenAsync(originalToken);
                    DownstreamRequest downstreamRequest = _httpContextAccessor.HttpContext.Items.DownstreamRequest();
                    request.Headers.Authorization = new AuthenticationHeaderValue("Bearer", tokenResult.AccessToken);
                    bool accessToken = downstreamRequest.Headers.TryGetValues("Authorization", out IEnumerable<string>? values);
                    downstreamRequest.Headers.TryAddWithoutValidation("Authorization", $"Bearer {tokenResult.AccessToken}");
                    downstreamRequest.Headers.TryAddWithoutValidation("NewToken", $"Bearer {tokenResult.AccessToken}");
                    _logger.LogInformation($"New Token: {request.Headers.Authorization}");
                }
            }
        }
    }
}

[raman-m]

Kindly add me as a collaborator to your prototype repository here.
So, I am going to upload some code...

---

Here are my testing results

All custom headers were successfully received by the downstream service ✔️

Also, Downstream Headers transform works fine:

Returning to your statement:

You should check why Ocelot has that behavior for the http since I have services that communicate with other services in my company using http and with custom headers, and they work fine.

I am intrigued by your observation. I have thoroughly reviewed the http downstream scheme, and everything appears to be functioning perfectly.

P.S. Add me as a collaborator, and I'll upload the complete solution I used for testing. After that, you'll need to send requests during the debug session using the OcelotPrototypeApp.http file.

[siualpinto]

Hi
I did remove app.UseHttpsRedirection(); from my downservice, and it is working now for HTTP. I just don't know why my services can communicate with each other using HTTP and with app.UseHttpsRedirection(); in the program, but with Ocelot, I can't do the same.
Either way, thank you for your cooperation and for all your work in Ocelot.

[raman-m]

I did remove app.UseHttpsRedirection(); from my downservice, and it is working now for HTTP.

LoL I did the same in commit siualpinto/OcelotPrototype@87b335a

I just don't know why my services can communicate with each other using HTTP and with app.UseHttpsRedirection(); in the program, but with Ocelot, I can't do the same.

I think the issue lies in the missing launchSettings.json file in the repository, which was excluded due to your .gitignore. I suggest including this file, at least for running apps in Visual Studio, so I added it in this commit → siualpinto/OcelotPrototype@41208c8
Your development environment should now match mine.

To be honest, you need to attach ports and URLs in the web app builder (explicitly); otherwise, Visual Studio and default web builder will implicitly use the launchSettings.json file to bind the ports automatically.

Your next steps

Run the updated applications in Visual Studio with consoles, verify my previous testing results, and ensure everything operates smoothly without any bugs in Ocelot.

[siualpinto]

Hi @raman-m
I confirm the tests have the same results as you with the commented //app.UseHttpsRedirection(); in the HeaderLoggingApp (downstream service)
If not commented, the headers didn't pass.
I think the conclusion that we get from all this discussion is that if someone is using the ocelot to make downstream requests using http, they should be careful with the .net config app.UseHttpsRedirection().

[raman-m]

If not commented, the headers didn't pass.

The app.UseHttpsRedirection() middleware triggers an internal redirect, resulting in a 3xx status code for the first http scheme request. This causes all headers to be lost, and depending on the client's behavior, a second https scheme request may be sent to the same endpoint based on the Location header from the initial response. This highlights the importance of manually binding upstream hosts and ports in microservices, as browsers often issue a second request for 3xx responses, leading to header loss.

HTTP theory aka 3xx statuses

🔁 What Happens to Headers During a 3xx Redirect?

When a client (like a browser or HttpClient) receives a 3xx response (e.g., 301, 302, 307, 308), it may automatically follow the redirect. But headers from the original request are not automatically forwarded unless explicitly configured.

🔍 Key Points:

• Request headers are not preserved across redirects by default.

• Authentication headers (e.g., Authorization) are dropped unless the redirect is to the same origin.

• Custom headers (e.g., X-Correlation-ID) are lost unless the client re-adds them manually.

🧠 Why This Happens

This behavior is intentional to prevent leaking sensitive headers to untrusted domains. For example, if a request with a bearer token is redirected to another domain, forwarding the token could be a security risk.

⚙️ How to Preserve Headers

In .NET HttpClient:

You must handle redirects manually if you want to preserve headers:

C#

var handler = new HttpClientHandler
{
    AllowAutoRedirect = false // disable automatic redirect
};
var client = new HttpClient(handler);

Then manually follow the redirect and reapply headers.

In Browsers:

You cannot control this directly—browsers drop headers like Authorization on cross-origin redirects.

🧪 Redirect Types Matter

Status	Method Changed?	Headers Preserved?
301/302	May change to GET	No (headers dropped)
307/308	Method preserved	No (headers dropped unless manually re-added)

[raman-m]

ASP.NET theory

Here is disassembled code of the UseHttpsRedirection(IApplicationBuilder) method (the source):

    public static IApplicationBuilder UseHttpsRedirection(this IApplicationBuilder app)
    {
        ArgumentNullException.ThrowIfNull(app);

        var serverAddressFeature = app.ServerFeatures.Get<IServerAddressesFeature>();
        if (serverAddressFeature != null)
        {
            app.UseMiddleware<HttpsRedirectionMiddleware>(serverAddressFeature);
        }
        else
        {
            app.UseMiddleware<HttpsRedirectionMiddleware>();
        }
        return app;
    }

Thus, this method adds the HttpsRedirectionMiddleware (the source), and the interesting method is Task Invoke(HttpContext) and especially this code block (lines L101-L114)

        var request = context.Request;
        var redirectUrl = UriHelper.BuildAbsolute(
            "https",
            host,
            request.PathBase,
            request.Path,
            request.QueryString);

        context.Response.StatusCode = _statusCode;
        context.Response.Headers.Location = redirectUrl;

        _logger.RedirectingToHttps(redirectUrl);
        return Task.CompletedTask;

Finally, it constructs a new https URL for the Location header, sets a 3xx status, and halts the current request processing by immediately returning CompletedTask from the middleware, effectively stopping the pipeline.