Today I ran into an interesting problem. I have an endpoint that looked something like this http://mydomain.com/my/api/interesting-dynamic-token/widgets
The interesting dynamic token gets replaced with an actual identifier value from the system. The token is an identifier in regular text that helps find the item on the back end. Everything worked smoothly until with every item, except for one. This item contained a value with spaces and ampersand in it (e.g. ‘Earl & James’). Almost all the other items had spaces in them so that wasn’t the problem.
I was making the call from a client application over to the api. For some reason I was getting a 500 error. I have access to the end point so I decided to debug on the end point and no matter what I did it appeared to never reach the Web API end point. All the other items that did not contain the ‘&’ character in the name worked just find.
You might be thinking that it reached the other side just not the end point, but no matter how hard I tried it seemed not reach any part of the application hosting the end point. I have filters that run and it didn’t reach them either.
At first I figured that it was just a matter of encoding the special character. So I tried HttpUtility.UrlEncode to encode just the interesting-dnaymic-token and it encoded the token but it still did not reach the other end. Same error. I all tried escape and encodeUrlPath. They yielded different results but none of them worked.
I found this blog post that helped explain a bit of what was going on.
While I was working the issue an awesome co-worker figured out the issue and actually tested it.
Here is a blog post that he found to help him solve it.
So… the reason that encoding doesn’t work is because even if you encode the ampersand in the path, IIS rejects it (yes IIS will reject http://mydomain.com/bartles%20%26%20james/items. At that point you can either create your own encoding or preferably don’t use interesting-dynamic-tokens in your path that may contain reserved characters.
I guess that might have gave it away. The character ‘&’ along with a few others is considered reserved and you cannot encode it with existing utilities and you probably should not create your own encoding utility either. Well… let me rephrase you can encode it but IIS will reject even the encoded version, unless you create your own encoding utility. But… I would think that creating your own encoding would lead to many more different types of problems, so… please don’t do that.
You can read a lot more about encoding URLs here
Until next time…