2
votes

Due to certain customer requirements our Azure API Management must be able to handle GET requests with URLs containing hash signs (#). Alas, I can't find a way to make it work.

So, let's imagine there is a following url template: /products/{id}/items, where {id} is a string which may contain #.

What I did is that {id} is encoded when called from the web application, so example call to the APIM is: https://contoso.apim.com/products/some%23id/items, where %23 is encoded # sign.

Such url is handled correctly when used against actual API (which, btw. is a .net core 3 api deployed to Service Fabric cluster), however when used via APIM management, request returns 404 FABRIC_E_SERVICE_DOES_NOT_EXIST error.
If I were to replace %23 with any other encoded value, e.g. %20, uri template would be correctly matched and hit underlying API.

After running some APIM request traces, I can definitely confirm that url thats being forwarded to the backend from APIM is not trimmed or changed in any way.

Any suggestion how to solve this would be much appreciated.

1
how you set backend via set-backend-service policy?Anton Komyshan
How did you request the APIM url and the actual API ? In postman ? or in chrome browser ? or anyother way ? And did you do any configuration in APIM policy ?Hury Shen
@AntonKomyshan, I do not set any - its using base API address specified in the configurationszachmat
@HuryShen, I tested it from both postman and web app (local and deployed in azure, browsed in Chrome)szachmat
Hi @HuryShen, I ended up contacting MS support. Once it's resolved I will post an answer to the question.szachmat

1 Answers

1
votes

It took some time, but eventually MS team found that this is a bug in Service Fabric reverse proxy that will be fixed in the near future. The workaround I had to use involved moving parameters from route to query parameter where # encoding is handled correctly.

31.03.2021 Update: Service Fabric 7.2 CU7 has been released, containing fix for described issue.