How to handle Ajax JQUERY POST request with WCF self-host

Question

There are many reasons create a RESTful WCF server (it is easy) and even better if you can avoid ASP and it's security box (if all you are doing is simple requests to return information). See: http://msdn.microsoft.com/en-us/library/ms750530.aspx on how to do this.

What I found is that handling AJAX (JQUERY) GET requests is easy. But dealing with JSON in a POST is tricky.

Here is an example of a simple GET request contract:

    [OperationContract]
    [WebGet(ResponseFormat = WebMessageFormat.Json)]
    String Version();

And the implementaion is here (which returns a JSON)

    public partial class CatalogService : ICatalogService
{
    public String Version()
    {
        mon.IsActive = true;
        this.BypassCrossDomain();
        ViewModel.myself.TransactionCount++;
        return ViewModel.myself.VersionString;
    }
}

Ah, but what if you want to POST some JSON. You will find lots of articles on stack overflow that tell you all you have to do is this:

    [OperationContract]
    [WebInvoke(Method = "POST", RequestFormat = WebMessageFormat.Json, ResponseFormat = WebMessageFormat.Json)]
    BuildResponse BuildToby(BuildRequest request);

which will receive a JSON message, de-serialize into a Plain .NET object (PONO) and let you work with it. And indeed, this worked fine when I constructed the request in Fiddler.

POST /BuildToby HTTP/1.1
User-Agent: Fiddler
Content-Type: application/json
Host: localhost:4326
Content-Length: 1999

However, when you use the following AJAX in JQUERY 1.8, you will find a SURPRISE:

It by specifying content-type of "application/json" you will find that there is a "preflight" check that is fired off by the browser to see if you are allowed to POST something other than a www-url-encloded post message. (there are notes in stack overflow about this).

    var request = JSON.stringify({ FrameList: ExportData.buildList });
    var jqxhr = $.ajax({
    type: "POST",
    url: "http://localhost:4326/BuildToby",
    data: request,
    contentType: "application/json; charset=utf-8",
    dataType: "json"
});

and here is what fiddler reports: (Note it is not a POST message, but a OPTIONS message).

OPTIONS http://localhost:4326/BuildToby HTTP/1.1
Host: localhost:4326
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Origin: http://ysg4206
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

What has happened is that a browser (in this case Firefox) has to make a extra call to the server, with a OPTIONS HTTP message, to see if a POST is allowed (of this content type).

All the articles about fixing this are about editing GLOBAL.ASAX which is fine if you are in ASP.NET but are useless if you are doing a self-host WCF.

So now you see the question (sorry for being so long winded, but I wanted to make this a complete article so that others can follow the results).

Answer 1

Ok, now there are some real MSDN gurus out there who have written solutions, but I cannot figure them out: http://blogs.msdn.com/b/carlosfigueira/archive/2012/05/15/implementing-cors-support-in-wcf.aspx

But I have come up with a simple solution. At least in WCF 4.5 you can add your own OperationContract for dealing with OPTIONS requests:

    [OperationContract]
    [WebInvoke(Method = "OPTIONS", UriTemplate = "*")]
    void GetOptions();

Note that the method signature is void, and has no arguments. This will get called first, and then the POST message will be called.

The implementation of GetOptions is:

    public partial class CatalogService : ICatalogService
{
    public void GetOptions()
    {
        mon.IsActive = true;
        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "*");
        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Methods", "POST, GET, OPTIONS");
        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Headers", "Content-Type");
    }
}

and that is really all you have to do.

You might also want to add this attribute to your service class, so that you can serialize large JSON:

//This defines the base behavior of the CatalogService. All other files are partial classes that extend the service
[ServiceBehavior(MaxItemsInObjectGraph = 2147483647)]       // Allows serialization of very large json structures
public partial class CatalogService : ICatalogService
{
    PgSqlMonitor mon = new PgSqlMonitor();

    private void BypassCrossDomain()
    {
        WebOperationContext.Current.OutgoingResponse.Headers.Add("Access-Control-Allow-Origin", "*");
    }
}

Note I have a little helper method called BypassCrossDomain() which I call on all my POST and GET methods, so that I can deal with cross domain calls.

I spent a lot of research time here (in MSDN forums, stack overflow, blogs) and I hope this will help others trying to do these sorts of projects.

Answer 2

One other addition to Dr.YSG's answer, if you need to support the OPTIONS method on endpoints which take POSTS to individual IDs, you will have to implement multiple GetOptions methods:

    [WebInvoke(Method = "OPTIONS", UriTemplate = "")]
    void GetOptions();
    [WebInvoke(Method = "OPTIONS", UriTemplate = "{id}")]
    void GetOptions(string id);

Its really disappointing that WCF/Microsoft can't automatically generation the proper OPTIONS response based on the signature of the endpoint automatically, but at least it can be handled manually.