I use C# a lot to write small utilities and sometimes find that it is annoying to have to dig into the source code to figure out why .Net framework doesn’t work as I expected. This happens again when I am using LinkedIn API (BTW, this is the first occurence of such experience).
LinkedIn API allows you to get the details of user’s connection using url like the following:
http://api.linkedin.com/v1/people/url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Flbeebe/connections
However, if you create a url like the above in C# and send the request to LinkedIn, the server will reject the request and complain about the wrong signature.
I hit this kind of issue several times before (due to slightly different escaping rules between the requirement of oAuth 1.0 3.6 / 2 (RFC3986) and Uri.EscapeUriString in .Net 2.0 (RFC2396)). But this time, the root cause is different.
After spending lots of time debugging by myself and searching the web later, I reached the following post: http://connect.microsoft.com/VisualStudio/feedback/details/94109/
So it is clear that .Net framework explicitly alters the input url for ‘security’ reason. But it doesn’t expose the interface to allow the user to change this behavior (even if it is simply a parser flag called ‘GenericUriParserOptions.DontUnescapePathDotsAndSlashes’ which can be set internally).
Well, I’m on my own to hack it. The workaround posted in the bug changes the parser flag for all Uri objects with the same url scheme, so I have to write a more isolated version:
However, I feel guilty for hacking.