Host header is changed too late when using UseHostHeaderForRequestUrl

[khellang]

Describe the bug

When running the backend ASP.NET app with the following app setting:

<add key="aspnet:UseHostHeaderForRequestUrl" value="true" />

The Host header from the backend app will be used to build Request.Url instead of the forwarded proxy host.

This seems to be because the Host header from X-Forwarded-Host is set too late in the pipeline and that Request.Url has already been calculated.

To Reproduce

Add the following app setting to the backend ASP.NET app:

<add key="aspnet:UseHostHeaderForRequestUrl" value="true" />

Inspect Request.Url in the app. It should show the host of the backend app, not the proxy.

Further technical details

ASP.NET Framework Application:

• Technologies and versions used (i.e. MVC/WebForms/etc): MVC, WebForms, WebAPI
• .NET Framework Version: 4.8.4515.0
• IIS Version: 10.0.19041.320
• Windows Version: 21H2

ASP.NET Core Application:

• Targeted .NET version: net6.0
• .NET SDK version: 6.0.400

[khellang]

I tried setting a breakpoint where the Url ends up being built, this is the stack trace I'm getting:

System.Web.dll!System.Web.HttpRequest.BuildUrl(System.Func<string> pathAccessor = {Method = {System.Reflection.RuntimeMethodInfo}}) Line 2274
System.Web.dll!System.Web.HttpRequest.Url.get() Line 925
Microsoft.Owin.Host.SystemWeb.dll!Microsoft.Owin.Host.SystemWeb.OwinCallContext.Microsoft.Owin.Host.SystemWeb.CallEnvironment.AspNetDictionary.IPropertySource.GetRequestQueryString() Line 96
Microsoft.Owin.Host.SystemWeb.dll!Microsoft.Owin.Host.SystemWeb.CallEnvironment.AspNetDictionary.RequestQueryString.get() Line 278
Microsoft.Owin.Host.SystemWeb.dll!Microsoft.Owin.Host.SystemWeb.CallEnvironment.AspNetDictionary.PropertiesTryGetValue(string key, out object value) Line 1078
Microsoft.Owin.Host.SystemWeb.dll!Microsoft.Owin.Host.SystemWeb.CallEnvironment.AspNetDictionary.TryGetValue(string key = "owin.RequestQueryString", out object value = null) Line 85
Microsoft.Owin.dll!Microsoft.Owin.OwinRequest.Get<string>(string key) Line 370
Microsoft.Owin.dll!Microsoft.Owin.OwinRequest.QueryString.get() Line 126
Microsoft.Owin.dll!Microsoft.Owin.OwinRequest.Uri.get() Line 145
System.Web.Http.Owin.dll!System.Web.Http.Owin.HttpMessageHandlerAdapter.CreateRequestMessage(Microsoft.Owin.IOwinRequest owinRequest = {Microsoft.Owin.OwinRequest}, System.Net.Http.HttpContent requestContent = {System.Net.Http.StreamContent})Unknown
System.Web.Http.Owin.dll!System.Web.Http.Owin.HttpMessageHandlerAdapter.InvokeCore(Microsoft.Owin.IOwinContext context = {Microsoft.Owin.OwinContext}, Microsoft.Owin.IOwinRequest owinRequest = {Microsoft.Owin.OwinRequest}, Microsoft.Owin.IOwinResponse owinResponse = {Microsoft.Owin.OwinResponse})Unknown
Hangfire.Core.dll!Microsoft.Owin.Mapping.MapMiddleware.Invoke(System.Collections.Generic.IDictionary<string, object> environment = {Microsoft.Owin.Host.SystemWeb.CallEnvironment.AspNetDictionary})Unknown
Microsoft.Owin.Host.SystemWeb.dll!Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContextStage.RunApp(System.Func<System.Collections.Generic.IDictionary<string, object>, System.Threading.Tasks.Task> entryPoint = {Method = {System.Reflection.RuntimeMethodInfo}}, System.Collections.Generic.IDictionary<string, object> environment = {Microsoft.Owin.Host.SystemWeb.CallEnvironment.AspNetDictionary}, System.Threading.Tasks.TaskCompletionSource<object> tcs = {System.Threading.Tasks.TaskCompletionSource<object>}, Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.StageAsyncResult result = {Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.StageAsyncResult}) Line 84
Microsoft.Owin.Host.SystemWeb.dll!Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContextStage.BeginEvent(object sender, System.EventArgs e, System.AsyncCallback cb, object extradata) Line 76
System.Web.dll!System.Web.HttpApplication.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() Line 327
System.Web.dll!System.Web.HttpApplication.ExecuteStepImpl(System.Web.HttpApplication.IExecutionStep step) Line 3599
System.Web.dll!System.Web.HttpApplication.ExecuteStep(System.Web.HttpApplication.IExecutionStep step = {System.Web.HttpApplication.AsyncEventExecutionStep}, ref bool completedSynchronously = false) Line 3627
System.Web.dll!System.Web.HttpApplication.PipelineStepManager.ResumeSteps(System.Exception error) Line 1165
System.Web.dll!System.Web.HttpApplication.BeginProcessRequestNotification(System.Web.HttpContext context, System.AsyncCallback cb) Line 4058
System.Web.dll!System.Web.HttpRuntime.ProcessRequestNotificationPrivate(System.Web.Hosting.IIS7WorkerRequest wr = {System.Web.Hosting.IIS7WorkerRequest}, System.Web.HttpContext context = {System.Web.HttpContext}) Line 1403
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext = 0x000001423bf600b8, System.IntPtr moduleData, int flags) Line 461
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) Line 386
[Native to Managed Transition]
[Managed to Native Transition]
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) Line 499
System.Web.dll!System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(System.IntPtr rootedObjectsPointer, System.IntPtr nativeRequestContext, System.IntPtr moduleData, int flags) Line 386
[AppDomain Transition]

[khellang]

Ah, it seems that ProxyHeaderModule does, in fact, set SERVER_NAME, SERVER_PORT and Request.Headers["Host"] using the forwarded headers - before it's attempting to build the Url property.

It's just that HttpWorkerRequest.GetKnownRequestHeader returns the wrong value. Apparently setting those things at the ASP.NET level doesn't pipe it back down to IIS.

[adityamandaleeka]

@HaoK can you please take a look at this and see if there's something we can do better here?

[HaoK]

@Tratcher so I debugged this and looks like IIS7WorkerRequest will cache the known headers early on, via this call stack, after which setting the host headers won't affect anything since its cached into the _knownRequestHeaders. Not sure if there's anything we can do about this

https://github.com/microsoft/referencesource/blob/master/System.Web/Hosting/IIS7WorkerRequest.cs#L741

>	System.Web.dll!System.Web.Hosting.IIS7WorkerRequest.ReadRequestHeaders() Line 1241	C#
 	System.Web.dll!System.Web.Hosting.IIS7WorkerRequest.GetKnownRequestHeader(int index) Line 741	C#
 	System.Web.dll!System.Web.HttpWorkerRequest.HasEntityBody() Line 1181	C#
 	System.Web.dll!System.Web.HttpRequest.GetEncodingFromHeaders() Line 933	C#
 	System.Web.dll!System.Web.HttpRequest.ContentEncoding.get() Line 1333	C#
 	System.Web.dll!System.Web.HttpRequest.QueryStringEncoding.get() Line 1359	C#
 	System.Web.dll!System.Web.HttpRequest.QueryStringText.get() Line 2087	C#
 	System.Web.dll!System.Web.HttpRequest.ValidateInputIfRequiredByConfig() Line 2634	C#
 	System.Web.dll!System.Web.HttpApplication.PipelineStepManager.ValidateHelper(System.Web.HttpContext context) Line 4343	C#

[khellang]

It does seem like the HttpHeaderCollection should pipe the request header back down to IIS7WorkerRequest:

https://github.com/microsoft/referencesource/blob/5697c29004a34d80acdaf5742d7e699022c64ecd/System.Web/HttpHeaderCollection.cs#L110-L112

Which in turn seems to pipe it back through to IIS:

https://github.com/microsoft/referencesource/blob/5697c29004a34d80acdaf5742d7e699022c64ecd/System.Web/Hosting/IIS7WorkerRequest.cs#L2007-L2028

The weird thing is that this doesn't update the cached _knownRequestHeaders array, which ends up passing back the old cached value to BuildUrl:

https://github.com/microsoft/referencesource/blob/5697c29004a34d80acdaf5742d7e699022c64ecd/System.Web/HttpRequest.cs#L1939

In any case, it doesn't seem there's a way to solve this without code changes to System.Web 😞

[HaoK]

Yeah, this looks like a bug in System.Web unfortunately :(

[khellang]

Yeah, this looks like a bug in System.Web unfortunately :(

And that leaves the bar super super high to get it fixed? 😟

[Tratcher]

Time for a reflection hack?

[HaoK]

So twiddle the field in proxy module when we set things?

[Tratcher]

Right

[HaoK]

Ok private reflection works, verified on the contact page which prints the request.url in the mvccoreapp, after doing this reflection to flip the flag in the proxy module, the url will now be correct

                // Need to use reflection to force HttpRequest to update the known headers
                var wrField = typeof(HttpRequest).GetField("_wr", BindingFlags.NonPublic | BindingFlags.Instance);
                var workerRequest = wrField.GetValue(request);
                var iis7WorkerRequestType = Assembly.GetAssembly(typeof(HttpRequest)).GetType("System.Web.Hosting.IIS7WorkerRequest");
                var requestHeaderAvailableField = iis7WorkerRequestType.GetField("_requestHeadersAvailable", BindingFlags.NonPublic | BindingFlags.Instance);
                requestHeaderAvailableField.SetValue(workerRequest, false);

Before the fix: Url: https://localhost:44339/Home/Contact (Shows the framework backend Url)
After the fix: Url: https://localhost:55442/Home/Contact (Shows the core app url)

If we are happy with this direction I can open a PR

[khellang]

Assuming it's safe to read the headers multiple times, I guess it's OK, but it does a lot of unnecessary work when you could just surgically insert the new value into the cached array 😉