CODEWITHSUNDEEP
c#.netazuredotnet-httpclient
cbailiss
cbailiss

Reputation: 1344

System.Uri Class: Different escaping behaviour in Azure vs. .Net Framework

I have the following code in a class library project (the Url has been simplified but it still demonstrates the same behaviour):

Uri oUri = new Uri("https://xzyserver.com/MyFolder%2FMyPage?querystring");

I have found that the System.Uri class is unescaping my Urls differently locally vs. in an Azure Worker Role.

If the class library runs in a desktop app oUri.AbsoluteUri returns different values to that running in Azure (both in the Compute Emulator and in a production worker role):

Locally = MyFolder%2FMyPage?querystring

InAzure = MyFolder/MyPage?querystring

(I have had to remove the start of the URLs in the two lines above because Stack Overflow was telling me there are too many links in my post)

The local behaviour is what I need (as part of a third party authentication process, a security token is calculated based on the request Uri and other parts of the request body, this unescaping breaks that process). The Uri is used with the classes in the System.Net.Http namespace.

I have tried the obsolete form of the Uri constructor (sUri, bDontEscape) but this didn't make any difference.

Further, the behaviour seems inconsistent - I also tried the following:

Uri oUri = new Uri("https://xzyserver.com/MyFolder%252FMyPage?querystring");

However, the unescaping only seems to apply to %2F to "/", the %25 didn't unescape back to "%", instead oUri.AbsoluteUri returns the full original Url with no unescaping.

Is this a known/documented problem? Any simple workaround that I may have missed?

PS. The classes in the System.Net.Http namespace take either a Uri object or a string Uri in many of their constructors, but the same issue applies to both. I expect the classes are simply creating a Uri under the covers for the string based overloads.

Upvotes: 3

Views: 316

Answers (1)

cbailiss
cbailiss

Reputation: 1344

After further research, I have discovered this behaviour is by design but can be crudely controlled from the app.config file from .net 4.0 onwards.

http://msdn.microsoft.com/en-us/library/ee656542(v=vs.110).aspx

The documentation suggests the default behaviour should be as Azure. I cannot find the override configured for my local system (perhaps the default for a client desktop installation is that the override is enabled?). No matter really, at least I understand the behaviour now.

Adding the override into the Azure worker role app.config file has solved the problem.

Upvotes: 1

Related Questions