Allow overriding the host header if doesn't match the absolute-form host #39334
Conversation
ghost
added
the
|
Hi @Tratcher. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document. |
|
Hi @Tratcher. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge. To learn more about how to prepare a servicing PR click here. |
src/Servers/Kestrel/test/InMemory.FunctionalTests/BadHttpRequestTests.cs
Outdated
Show resolved
Hide resolved
| private Func<string, Encoding?> _responseHeaderEncodingSelector = DefaultHeaderEncodingSelector; | ||
|
|
||
| private bool? _enableInsecureAbsoluteFormHostOverride; | ||
| internal bool EnableInsecureAbsoluteFormHostOverride |
There was a problem hiding this comment.
Is a public version of this the API proposal for .NET 7?
There was a problem hiding this comment.
Should we allow for a missing Host header if this is set and there's an absolute form request target?
There was a problem hiding this comment.
The customer is currently asking for a short term mitigation, it's not clear we'll still need this in 7.0.
Should we allow for a missing Host header if this is set and there's an absolute form request target?
We could expand to that if needed, but it hasn't come up yet. So far the client is sending a Host header, but it's malformed.
There was a problem hiding this comment.
I think it's weird to require a HOST header if we're going to ignore it anyway. What does httpsys do?
There was a problem hiding this comment.
Http.Sys also always requires the Host header to be present (even if empty), even if it overrides it with the host from the request line.
leecow
added
Servicing-approved
Co-authored-by: Stephen Halter <[email protected]>
|
@dotnet/aspnet-build please merge. |
…ost (dotnet#39334) * Allow overriding the host header if doesn't match the absolute-form host * Apply suggestions from code review Co-authored-by: Stephen Halter <[email protected]>
…ost (dotnet#39334) * Allow overriding the host header if doesn't match the absolute-form host * Apply suggestions from code review Co-authored-by: Stephen Halter <[email protected]>
amcasey
added
area-networking
…ost (dotnet#39334) * Allow overriding the host header if doesn't match the absolute-form host * Apply suggestions from code review Co-authored-by: Stephen Halter <[email protected]>
* Allow overriding the host header if doesn't match the absolute-form host (#39334) * Allow overriding the host header if doesn't match the absolute-form host * Apply suggestions from code review Co-authored-by: Stephen Halter <[email protected]> * Add explanatory comment * Replace internal API and appcontext switch with public API The new public API is `KestrelServerOptions.AllowUnsafeHostHeaderOverride` and I've moved the explanatory comments there. The behavior remains opt-in. * Separate corruption and mismatch tests * Rename property per API review * Clarify comment. Co-authored-by: Chris Ross <[email protected]> --------- Co-authored-by: Chris Ross <[email protected]> Co-authored-by: Stephen Halter <[email protected]> Co-authored-by: Chris Ross <[email protected]>
Description
There are known clients that send the request with the full url in the request line, but then also include a malformed or mismatched Host header. IIS/Http.Sys ignores the invalid host in this scenario, where Kestrel rejects it with a 400. This change provides an opt-in switch for customers to test this new approach in Kestrel.
Fixes #39335
Customer Impact
Some clients are not able to communicate with Kestrel, and updating the client isn't in the customer's control.
Regression?
[If yes, specify the version the behavior has regressed from]
Risk
Opt-in validation change.
Verification
Packaging changes reviewed?