DotNetCore API hosted via Azure App Service is stripping leading url encoded forward slash from route values.

[ccromer]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When an ASPNetCore(net6.0) API is hosted under an Azure App Service, any route value that begins with an encoded forward slash is having the route value altered where the encoded forward slash is being removed prior to reaching the API Controller Action. I have taken this issue up with Azure support and they claim this to be a .Net Core issue, hence why I'm raising the issue here. I am unable to reproduce the issue outside of an Azure App Service. The issue only occurs when the 1st encode character is a forward slash.

Expected Behavior

To not have the route value altered by the pipeline/framework.

Steps To Reproduce

Repo: https://github.com/ccromer/AzureAppServiceAndEncodedRouteParams.git

I have published the demo API from the above repo and you can reproduce this issue by making a GET call to:

https://ccllc.azurewebsites.net/api/routes/%2Ftest

The url encoded forward slash is gone by the time it reaches the controller action where only "test" is received. Running the API locally returns a value having the %2F in the value where it can be properly url decoded.

Further inspection shows other leading url encoded characters do make it to the controller action as in:

https://ccllc.azurewebsites.net/api/routes/%40test

The difference here is that the url encoded At symbol is decoded before it reaches the controller action (which is also diff behavior when %2F is used when run locally).

Exceptions (if any)

No response

.NET Version

.Net 6 lts

Anything else?

[javiercn]

@ccromer thanks for contacting us.

You seem to be receiving the right value when querying localhost, it is only when you are on Azure App Service that you do not get the result you expect.

I suspect the reason for that is that the URL is being manipulated at some point in App Service and by the time it gets to ASP.NET Core it has already been decoded/transformed.

[javiercn]

/cc: @Tratcher do you have further thoughts?

[ccromer]

Hey Javier, I do find it odd that in the case of the encoded forward slash the controller action is receiving the encoded value and in the case of any other encoded character, such as the At symbol, we receive the decoded value (when run locally). This is definitely an issue and forces the developer to manually decode the value after it is received at the controller action level. I do agree that the Azure pipeline is altering the value once it is deployed to the App Service. So here is where I stand, I am a consumer of a Microsoft product using a Microsoft service and there is an issue at both the framework and service levels (a perfect storm it appears to be). As your client I am not concerned with who owns the issue from an external standpoint, this is a bug impacting the ability to deliver a reliable service using Microsoft technologies. Right now I'm in the middle of two teams pointing fingers at one another and that is not doing me or my consumers any justice and is impacting the ability to meet deliverables. I have added Brian to this email since he has been working on the issue from the Azure perspective. Regards, CC -

…

On Tue, Oct 11, 2022 at 5:22 AM Javier Calvarro Nelson < ***@***.***> wrote: @ccromer <https://github.com/ccromer> thanks for contacting us. You seem to be receiving the right value when querying localhost, it is only when you are on Azure App Service that you do not get the result you expect. I suspect the reason for that is that the URL is being manipulated at some point in App Service and by the time it gets to ASP.NET Core it has already been decoded/transformed. — Reply to this email directly, view it on GitHub <#44461 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2MTL6WOEYRLTIN5EMCFV3WCU5VHANCNFSM6AAAAAARBZTGGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Chad Cromer ***@***.*** -

[ccromer]

Adding @carlo ***@***.***> from the PG team to the thread to share his perspective. @chad ***@***.***>, for the app on the cloud, can you go to the App Service Logs blade and turn on Failed Request Tracing? We may need them for this discussion. Thank you, Brian Baro From: Chad Cromer ***@***.***> Sent: Tuesday, October 11, 2022 4:48 AM To: dotnet/aspnetcore ***@***.***> Cc: dotnet/aspnetcore ***@***.***>; Mention ***@***.***>; Brian Baro ***@***.***>; Microsoft Support ***@***.***>; Bob Richter ***@***.***>; Chad Cromer ***@***.***> Subject: [EXTERNAL] Re: [dotnet/aspnetcore] DotNetCore API hosted via Azure App Service is stripping leading url encoded forward slash from route values. (Issue #44461) You don't often get email from ***@***.******@***.***>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hey Javier, I do find it odd that in the case of the encoded forward slash the controller action is receiving the encoded value and in the case of any other encoded character, such as the At symbol, we receive the decoded value (when run locally). This is definitely an issue and forces the developer to manually decode the value after it is received at the controller action level. I do agree that the Azure pipeline is altering the value once it is deployed to the App Service. So here is where I stand, I am a consumer of a Microsoft product using a Microsoft service and there is an issue at both the framework and service levels (a perfect storm it appears to be). As your client I am not concerned with who owns the issue from an external standpoint, this is a bug impacting the ability to deliver a reliable service using Microsoft technologies. Right now I'm in the middle of two teams pointing fingers at one another and that is not doing me or my consumers any justice and is impacting the ability to meet deliverables. I have added Brian to this email since he has been working on the issue from the Azure perspective. Regards, CC - On Tue, Oct 11, 2022 at 5:22 AM Javier Calvarro Nelson ***@***.******@***.***>> wrote: @ccromer<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fccromer&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107600377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hbw50XNory7SXX%2B3%2FscY%2F0T1GWMiEFlLCOrl5Ko6bhM%3D&reserved=0> thanks for contacting us. You seem to be receiving the right value when querying localhost, it is only when you are on Azure App Service that you do not get the result you expect. I suspect the reason for that is that the URL is being manipulated at some point in App Service and by the time it gets to ASP.NET<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fasp.net%2F&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107756611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=U1QNuPtEOA4Vs97GRKasiIGwKbFpteLqyFS%2F7XHf4JI%3D&reserved=0> Core it has already been decoded/transformed. - Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Faspnetcore%2Fissues%2F44461%23issuecomment-1274466364&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107756611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rK5v73cbg1WkxsQWr7cKI1BH19dygdykpn8LRcMwmvI%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA2MTL6WOEYRLTIN5EMCFV3WCU5VHANCNFSM6AAAAAARBZTGGA&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107756611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=32FESIQSdIP3kOHQ8RA4fBuj0MDwtObMs215m0Wf5DA%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

…

-- Chad Cromer ***@***.******@***.***> -

[ccromer]

I did so for the demo API used for the .net framework case: ***@***.*** GET: https://ccllc.azurewebsites.net/api/routes/%2Ftest Thanks, CC - From: Brian Baro ***@***.***> Sent: Wednesday, October 12, 2022 9:44 AM To: Chad Cromer ***@***.***>; Chad Cromer ***@***.***>; dotnet/aspnetcore ***@***.***>; Carlo Colombo ***@***.***>; Jeremy Brooks ***@***.***> Cc: dotnet/aspnetcore ***@***.***>; Mention ***@***.***>; Microsoft Support ***@***.***>; Bob Richter ***@***.***> Subject: RE: [EXTERNAL] Re: [dotnet/aspnetcore] DotNetCore API hosted via Azure App Service is stripping leading url encoded forward slash from route values. (Issue #44461) Adding @carlo ***@***.***> from the PG team to the thread to share his perspective. @chad ***@***.***>, for the app on the cloud, can you go to the App Service Logs blade and turn on Failed Request Tracing? We may need them for this discussion. Thank you, Brian Baro From: Chad Cromer ***@***.***> Sent: Tuesday, October 11, 2022 4:48 AM To: dotnet/aspnetcore ***@***.***> Cc: dotnet/aspnetcore ***@***.***>; Mention ***@***.***>; Brian Baro ***@***.***>; Microsoft Support ***@***.***>; Bob Richter ***@***.***>; Chad Cromer ***@***.***> Subject: [EXTERNAL] Re: [dotnet/aspnetcore] DotNetCore API hosted via Azure App Service is stripping leading url encoded forward slash from route values. (Issue #44461) You don't often get email from ***@***.******@***.***>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hey Javier, I do find it odd that in the case of the encoded forward slash the controller action is receiving the encoded value and in the case of any other encoded character, such as the At symbol, we receive the decoded value (when run locally). This is definitely an issue and forces the developer to manually decode the value after it is received at the controller action level. I do agree that the Azure pipeline is altering the value once it is deployed to the App Service. So here is where I stand, I am a consumer of a Microsoft product using a Microsoft service and there is an issue at both the framework and service levels (a perfect storm it appears to be). As your client I am not concerned with who owns the issue from an external standpoint, this is a bug impacting the ability to deliver a reliable service using Microsoft technologies. Right now I'm in the middle of two teams pointing fingers at one another and that is not doing me or my consumers any justice and is impacting the ability to meet deliverables. I have added Brian to this email since he has been working on the issue from the Azure perspective. Regards, CC - On Tue, Oct 11, 2022 at 5:22 AM Javier Calvarro Nelson ***@***.******@***.***>> wrote: @ccromer<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fccromer&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107600377%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hbw50XNory7SXX%2B3%2FscY%2F0T1GWMiEFlLCOrl5Ko6bhM%3D&reserved=0> thanks for contacting us. You seem to be receiving the right value when querying localhost, it is only when you are on Azure App Service that you do not get the result you expect. I suspect the reason for that is that the URL is being manipulated at some point in App Service and by the time it gets to ASP.NET<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fasp.net%2F&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107756611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=U1QNuPtEOA4Vs97GRKasiIGwKbFpteLqyFS%2F7XHf4JI%3D&reserved=0> Core it has already been decoded/transformed. - Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Faspnetcore%2Fissues%2F44461%23issuecomment-1274466364&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107756611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=rK5v73cbg1WkxsQWr7cKI1BH19dygdykpn8LRcMwmvI%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAA2MTL6WOEYRLTIN5EMCFV3WCU5VHANCNFSM6AAAAAARBZTGGA&data=05%7C01%7CBrian.Baro%40microsoft.com%7Cc615ee3a83e244030af608daab7e825d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638010857107756611%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=32FESIQSdIP3kOHQ8RA4fBuj0MDwtObMs215m0Wf5DA%3D&reserved=0>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

…

-- Chad Cromer ***@***.******@***.***> -

[adityamandaleeka]

@Tratcher PTAL

[crosenblatt]

Hi @ccromer - This behavior is present in App Service for backwards compatibility reasons. In order to get the raw bytes of the url exactly as they are received on the wire, you can use the header "X-Waws-Unencoded-Url".

[ghost]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.