Why does passing Host headers "break everything"?

[Zirias]

According to this documentation page, forwarding a Host header "obviously breaks everything". Unfortunately, it isn't so obvious to me. Just for experimentation, I added

            PreAuthorisationMiddleware = async (ctx, next) =>
            {
                ctx.DownstreamRequest.Headers.Host = ctx.HttpContext.Request.Headers["Host"];
                await next.Invoke();
            }

and so far, it doesn't break anything in my tests. Therefore, some clarification would be nice, thank you.

[gabor182]

Same question raised here. Nginx and other reverse proxies can forward the original host header (at least in the X-Forwarded-Host header key). Why is it a problem in Ocelot? A lot of the times the back-end services behind the API Gateway need the original Host header value (i.e. for generating URLs in the response) so I don't know why his feature has not been implemented here yet.

[raman-m]

We can consider forwarding X-Forwarded-Host header, but not Host one!
See the answer!

[nadafsak]

Just as an update to this, I used a variation of another solution on here to manually pass the original host from the upstream request to the downstream request:

Create the handler that will replace the downstream host header with the upstream value.

        public class HostInjectorDelegatingHandler : DelegatingHandler
        {
            private readonly IHttpContextAccessor _httpContextAccessor;

            public HostInjectorDelegatingHandler(IHttpContextAccessor httpContextAccessor)
            {
                _httpContextAccessor = httpContextAccessor;
            }

            protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
            {
                var host = $"{_httpContextAccessor.HttpContext.Request.Host.Value}";
                request.Headers.Add("Host",  host);
                return base.SendAsync(request, cancellationToken);
            }
        }

Add the handler to Ocelot init:

services.AddHttpContextAccessor(); // This is required to enable access to the HttpContext    
services.AddOcelot()
  .AddDelegatingHandler<HostInjectorDelegatingHandler>()

And then on my route:

     "UpstreamHost": "example.com",
      "DelegatingHandlers": [
        "HostInjectorDelegatingHandler"
      ]

[gboder]

I'm looking into options to allow specifying the DownstreamRequest Header Host value based on the route definition within the ocelot.json files. I can confirm that manipulation of Host values is breaking a lot of features. This property is used to transport some central information and is overwritten by the result of the Service Discovery implementation within the LoadBalacing middleware to carry the downstream host address. Letting external configuration or header manipulation alter this value and guarantee it is being kept along the request processing would required to change the logic how the downstream address is being read and transported over the Middlewares. Whereby this is not impossible it would break the existing behavior hence be a breaking change imho.

I guess the approach of having an extensibility mechanism allowing to overwrite / set this header value prior emitting the DownstreamRequest is the prefered way to go here. I'll built my solution around the example @nadafsak.