Skip to main content

WCF URI Template Url-Encoded Character Issues

I've been playing around with RESTFul services in WCF following by the MSDN topic, and have found the guide to be both extremely helpful, and the overall support provided to be excellent.  If you've been writing WCF services for your cloud service offerings, or even just AJAX methods for web-page code, you should find the migration over to RESTful services relatively easy to manage.

It also increases the accessibility of your services a huge amount - very basic jQuery code can be used, for example, to bind to these services.

However, there are some issues surrounding the types of values for parameters that can be bound in either a path or query string segment - and it's all down to some url-encoded characters, and how they get interpreted (or rather not interpreted) before being serialised into method parameters.

The following example is taken from a Microsoft Connect bug that I have posted:

Setup a project to host a WCF .svc and create a method with two parameters:

[WebGet(UriTemplate = "{willfail}?willwork={willwork}")]


public string Foo(string willfail, string willwork)


Trace.WriteLine("willfail: " + willfail);

Trace.WriteLine("willwork: " + willwork);

string toreturn = 

	string.Format("willfail: {0}. willwork : {1}", 

			willfail, willwork);

return toreturn;


In my example, I set the service to be hosted in Asp.Net under IIS (optional, as it turns out) - and I'm using the zero-configuration WebServiceHostFactory factory in the .svc file.

Now, after building, start up a browser and browse to the url that the service is configured on - e.g http://localhost/[baseuriofservice]/[svcfile.svc]/c%23?willwork=c%23.  '%23' is Url-Encoding-speak for '#'.

What you expect to see is "willfail: c#. willwork : c#".

What you actually see is "willfail: c. willwork: c#".

So, when url-encoded characters appear in path segments bound to parameters, they won't always be read correctly (incidentally '%20' is read correctly); but it appears that query-string ones will.

As I mentioned, I posted an Connect bug under the title 'WCF UriTemplate Strips Some UrlEncoded characters from bound path segment' - and it turns out that this behaviour doesn't just affect WCF, or even Asp.Net (since the MS investigator also tried self-hosting the service and it still fails).

Even better news, however, is that this bug has been marked as fixed - so hopefully in the next framework version, we can expect to be able to use path segments with the whole gamut of URL-encodings!

This is one in the eye for Ayende Rahien - who blogged very recently about Connect failing all over the place.


Popular posts from this blog

Serializing to attributes in WCF with DataContractSerializer

It’s a common problem – you want to return an object from a WCF service as XML, but you either want, or need, to deliver some or all of the property values as XML Attributes instead of XML Elements; but you can’t because the DataContractSerializer doesn’t support attributes (you’re most likely to have seen this StackOverflow QA if you’ve done a web search).  Most likely you’ve then migrated all your WCF service code to using the XmlSerializer (with all the XmlElement/XmlAttribute/XmlType attributes et al) – and you’ve cursed loudly.Well, I’m here to rescue you, because it is possible – and the answer to the problem is actually inferred from the MSDN article entitled ‘Types supported by the Data Contract Serializer’.The example I’m going to give is purely for illustration purposes only.  I don’t have a lot of time, so work with me!Create a new Asp.Net WCF service application, you can use Cassini as your web server (probably easier – otherwise you might have to enable Asp.Net compatibil…

Asp.Net 2 and 4 default application pool generates CS0016 IIS7.5

Before I start – if you’ve found a bunch of other articles about this around the net, tried the fixes that are mentioned and still not getting any joy – then read on – you might find this solves your problem. Earlier today I discovered that when I run any ASP.Net 2 or 4 application through IIS7.5 using the default application pools (which use ApplicationPoolIdentity) on Windows 2008 R2 x64 I get an error message similar to this: Server Error in '/MvcApplication31' Application. Compilation ErrorDescription: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0016: Could not write to output file 'c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\mvcapplication31\222b4fe6\4e80a86\App_global.asax.clb4bsnc.dll' -- 'The directory name is invalid. '
Source Error:[No relevant source lines]

Adding ‘Deny’ functionality to AuthorizeAttribute in Asp.Net Web API

For the web service project I’m working on at the moment I need to be able to treat authorization differently based on the hostname of the URL that requests are made through.To state more clearly – these web services will have a ‘sandbox’ mode in addition to the real mode, and the mode a request will operate under is determined as part of the controller-selection phase early in the Web API request lifecycle.  So, say that my web services will be hosted on; the sandbox will simply be note – a discussion of how this is implemented is entirely outside the scope of this article; but I’ll just say that I’ve developed an in-house multi-tenancy layer for both MVC 4 and Web API that allows us to define ‘brands’ and, under those, you can then redefine content, controllers, and even the DI container that is used.These services are going to require caller-level authentication for most operations via SCRAM Authentication (RFC 5802), and as such m…