1

I'm developing a RESTful web service with WCF and C#. The service works fine, but when I made a request from a static HTML page, using XMLHttpRequest, all browsers except IE (who else?) first send a prefligth message (https://developer.mozilla.org/en/http_access_control) requesting the available options for the service. This kind of messages only occur when I change the headers of the message in order to send a POST request.

My question/suggestion: do you know any way to give support to this kind of messages on WCF/.NET? My idea is to implement a method to handle the preflight message; the reply would be a standard reply message with all the available options (GET, PUT, POST, DELETE), because all this operations will be available, and also tells that the only type of data available for the data on the messages is JSON. After the reply the normal request would be sent by the browser, so everything should work right.

What do you think?

jmpcm
  • 1,814
  • 2
  • 19
  • 27
  • Why don't you simply append a LS (Layered System) solution and work with a reverse proxy? Sounds like a hassel to write a routine to simply being used for IE. – Anders Nov 11 '10 at 10:23
  • In this case IE it's not the problem, all the other are :P IE don't send the preflight message, so the service works fine. All the other browsers send the preflight message and it must be handled, therefore the need for the routine to handle it. Probably IE will have this feature implemented on the 9 version, so it's not really a hassel to write the routine because it will be needed in the future. – jmpcm Nov 15 '10 at 20:15

3 Answers3

1

You can support OPTIONS in the same way you support POST with the WebInvoke attribute. Just change the method. There is nothing special about the OPTIONS request. You just need to set the Allow header in the response.

Darrel Miller
  • 139,164
  • 32
  • 194
  • 243
  • Hi Darrel! Thanks for the answer and sorry about the delay. Look for the answer below. I've tried to put the OPTIONS on Method attribute, but it didn't worked... I solved it with *. Did you ever made this with OPTIONS on the Method attribtue? Thanks in advance! – jmpcm Nov 15 '10 at 11:30
  • @jmpcm No I have never used OPTIONS but I have used the PATCH method with WebInvoke. Not sure why the OPTIONS method did not work for you. – Darrel Miller Nov 20 '10 at 03:18
1

Problem solved! I've setted the Method attribute with * and now it works fine: first the preflight request is answered and then the real request is received and handled. Code follows:

[OperationContract]
[WebInvoke(UriTemplate="*", Method = "*")]
void HandleHttpOptionsRequest();
jmpcm
  • 1,814
  • 2
  • 19
  • 27
0
[OperationContract]
[WebInvoke(UriTemplate="*", Method = "*")]
void HandleHttpOptionsRequest();

This is a great solution and you can implement an IDispatchMessageInspector to add the necessary CORS headers quite easily.

dobos
  • 1
  • 1
    Welcome to Stack Overflow! This should probably have been a comment to the answer you got the code from, not an answer itself. With a bit more rep, [you will be able to post comments](http://stackoverflow.com/privileges/comment). – Nathan Tuggy Jan 22 '15 at 00:16