Azure is decoding characters in the URL before reaching the application

Jkuhl 35

In our backend API, we have an endpoint with a path variable and we need to be able to support certain special characters. To accomplish this, we are encoding the path variable with UTF-8 before hitting the endpoint. This works for most special characters, but the problem we are facing is that Azure is decoding some of the encoded characters before the application receives the request.

Use this endpoint as an example: GET: /example/{pathParam}/test

Say I need to provide "TEST/1" as the input. First I would encode the special character and hit the endpoint with this url: GET: /example/TEST%2F1.

This works fine when I am running the application locally, but when I hit the apps deployed on Azure, I receive a 404 not found error for path /example/TEST/1. Does anyone know if there is a way to prevent Azure from decoding characters in the URL before it sends the request to the application?

ajkuma 24,396 Reputation points Microsoft Employee

2023-01-13T14:36:53.8466667+00:00

@Jkuhl , Thanks for posting this question. Just to clarify, are you leveraging Azure App Service WebApp? Could you please share more information about your application framework?
ajkuma 24,396 Reputation points Microsoft Employee

2023-01-16T12:54:13.05+00:00

@Jkuhl , Just checking in to see if you had got a chance to see the previous response. Kindly share more details to help you better.
Simi Hartstein 5 Reputation points

2023-01-30T19:29:51.89+00:00

I am also seeing this issue using an Azure App Service WebApp running a custom Linux container. Running locally works fine, but the App Service decodes any %2F into slashes before my app receives the request. Related, it will also change %2F%2F into a single /.
ajkuma 24,396 Reputation points Microsoft Employee

2023-02-08T18:41:09.97+00:00

Apologies for the delay

By default, App Service decodes any %2F into slashes before the request is passed.

Checkout this doc for more info. This ensures that the URLs in the request match the URLs in your app's routing configuration.
Pablo López Ponce 10 Reputation points

2023-03-23T16:06:42.28+00:00

Is there any way to change that default behaviour?

It makes no sense to me, when running locally either on docker (using Kestrel) or on windows with IIS, the %2F is not decoded and reaches the appropriate endpoint.

However in Azure App Service (for containers on Linux), if I run the same image, I get different behaviour.

Basically when the url is something as:

GET /Items/someItem%2FWithForwardSlash

It doesn't hit my /Items/{reference} controller endpoint because %2F is being decoded to a forward slash, so the path doesn't match and I get a 404.

Running locally the same request does hit the endpoint with %2F still encoded, as expected (but not ideal) as explained here: https://video2.skills-academy.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-7.0#routing-with-special-characters
Kruzel, Jacek 0 Reputation points

2023-05-29T15:53:10.1366667+00:00

Acutally we experience exactly the same behaviour when using Azure Container Apps.

The GET url being: ... /package/@swo-web%2fdemo-react/dist-tags
Which reaches this container as /package/@swo-web/demo-react/dist-tags

That is critical for us to run, and it doesn't
ajkuma 24,396 Reputation points Microsoft Employee

2023-06-01T13:39:36.66+00:00

Kruzel, In Azure Container Apps, as you mentioned, the GET URL /package/@swo-web%2fdemo-react/dist-tags is received by the container as /package/@swo-web/demo-react/dist-tags. The %2f in the URL is URL-encoded as /, so the container receives the URL with the forward slash instead of the encoded %2f.

This is a common behavior in web applications and APIs, where URL-encoded characters are automatically decoded by the server before processing the request. In this case, the Azure Container Apps service automatically decodes the %2f in the URL to / before forwarding the request to the container.

Just to highlight, we have Azure Container Apps tag for receiving inputs from targetted SMEs/audience on Azure Container Apps questions.
Amine Mghirbi 0 Reputation points

2023-09-19T09:14:31.97+00:00

Helllo am having the same issue ! My URL is being decoded before reaching the API ! Do you have any suggestion or there is any workaround ! So that my api received the resuest as i sent it ?
Van Haute Tom 0 Reputation points

2023-12-14T12:42:57.21+00:00

Same issue here
Dhruval Dave 0 Reputation points

2024-01-10T10:10:39.8+00:00

@Jkuhl Have you tried Custom URL rewriting rules? You can introduce URL Rewritter Middleware and give it a try.
Dhruval Dave 0 Reputation points

2024-01-10T10:10:49.6033333+00:00

@Jkuhl Have you tried Custom URL rewriting rules? You can introduce URL Rewritter Middleware and give it a try.
Victor Trincado 1 Reputation point

2024-02-02T11:12:37.9433333+00:00
same here but with + or decoded %2B character Running locally works and the controller is hit. Over the app service it does not hit the controller
e.g.:

GET /api/12345/testtemp/myname+above.jpg

GET /api/12345/testtemp/myname%2Babove.jpg

most other characters work like äö,ÖÄ&.

[HttpHead("{file}/{templ}/{fileName}")] [HttpGet("{file}/{file}/{fileName}")] public async Task<ActionResult> Get(string file, string templ, string fileName)
Victor Trincado 1 Reputation point

2024-02-02T11:15:36.8666667+00:00

this comment can be deleted

1 answer

hossein jalilian 4,770 Reputation points

2024-02-02T21:45:51.8966667+00:00

Thanks for posting your question in the Microsoft Q&A forum.

Yes, this was a bug reported under issue number 9290 and was addressed in a fix that was implemented on October 12, 2023. You can find more details about the bug fix in the following GitHub pull request: https://github.com/Azure/azure-functions-host/pull/9402. Your issue should now be resolved.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful
Please sign in to rate this answer.

0 comments No comments
Sign in to comment

Share via

Azure is decoding characters in the URL before reaching the application

1 answer