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 endpoint so I decided to debug on the endpoint and no matter what I did it appeared to never reach the Web API endpoint. All the other items that did not contain the ‘&’ character in the name worked just fine.
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 to reach any part of the application hosting the endpoint. 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-dynamic-token and it encoded the token but it still did not reach the other end. Same error. I tried 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 that 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 given 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.
If you have items with that special character in your URL then you can resort to the older style queries (e.g. www.blah.com/resource?myAttribute=EncodedValuewithAmpersand
You can read a lot more about encoding URLs here
Until next time…