[release/6.0] Update Proxy-Support check to be case insensitive #79620
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
RFC4559 does not specify that the Proxy-Support header value used to determine if the proxy server will honour client server authentication integrity is case sensitive. Updating the check to be case insensitive to prevent failures when value is supplied using differences in case. Fix #61414
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackport of #61446 to release/6.0 /cc @karelz @ChrisFWood Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
|
Test failures are unrelated infra problems, happening also on rerun:
|
karelz
added
Servicing-approved
|
Approved via email by @SteveMCarroll on Sat 2022/12/17 1:00 AM -- adding Servicing-approved label
|
|
Approved by Tactics (6.0.14). |
ghost
locked as resolved and limited conversation to collaborators
Backport of #61446 to release/6.0
Fixes #61414
/cc @karelz @ChrisFWood
Customer Impact
A customer is in the middle of swapping internal proxy/load balancer. The new proxy does not play well with .NET applications, because it uses different casing of
Session-Based-Authenticationheader (header used by proxies), which is valid according to RFC, but .NET does not recognize it. As a result, 6,500 internal .NET applications are not working properly and the new proxy roll out is blocked.The fix is already part of .NET 7.0, but the customer has internal requirement to stay on LTS, therefore asks for 6.0 backport.
It is not a regression, it has been broken this way since .NET Core 2.0 when we introduced SocketsHttpHandler.
Testing
CI only
Working with the customer on private E2E validation, but it is not clear if it will be possible
Risk
Low, it is limited to proxy handling code paths only.
If the header was not recognized before, the application would not work properly, so the risk of breaking customers depending on broken scenario is low.