I recently ran into with posting Javascript requests to another domain. By default XHR posting to other domains is not allowed.
Following the instructions from htt
With ASP.net Web API 2 install Microsoft ASP.NET Cross Origin support via nuget.
http://enable-cors.org/server_aspnet.html
public static void Register(HttpConfiguration config)
{
var enableCorsAttribute = new EnableCorsAttribute("http://mydomain.com",
"Origin, Content-Type, Accept",
"GET, PUT, POST, DELETE, OPTIONS");
config.EnableCors(enableCorsAttribute);
}
The solution for me was to add :
<system.webServer>
<modules runAllManagedModulesForAllRequests="true">
<remove name="WebDAVModule"/>
</modules>
</system.webServer>
To my web.config
The 405 response is a "Method not allowed" response. It sounds like your server isn't properly configured to handle CORS preflight requests. You need to do two things:
1) Enable IIS7 to respond to HTTP OPTIONS requests. You are getting the 405 because IIS7 is rejecting the OPTIONS request. I don't know how to do this as I'm not familiar with IIS7, but there are probably others on Stack Overflow who do.
2) Configure your application to respond to CORS preflight requests. You can do this by adding the following two lines underneath the Access-Control-Allow-Origin
line in the <customHeaders>
section:
<add name="Access-Control-Allow-Methods" value="GET,PUT,POST,DELETE" />
<add name="Access-Control-Allow-Headers" value="Content-Type" />
You may have to add other values to the Access-Control-Allow-Headers
section based on what headers your request is asking for. Do you have the sample code for making a request?
You can learn more about CORS and CORS preflight here: http://www.html5rocks.com/en/tutorials/cors/
It took Microsoft years to identify the gaps and ship an out-of-band CORS module to solve this problem.
as below
<configuration>
<system.webServer>
<cors enabled="true" failUnlistedOrigins="true">
<add origin="http://*" allowed="true" />
</cors>
</system.webServer>
</configuration>
In general, it is much easier than your custom headers and also offers better handling of preflight requests.
In case you need the same for IIS Express, use some PowerShell scripts I wrote.
It is likely a case of IIS 7 'handling' the HTTP OPTIONS response instead of your application specifying it. To determine this, in IIS7,
Go to your site's Handler Mappings.
Scroll down to 'OPTIONSVerbHandler'.
Change the 'ProtocolSupportModule' to 'IsapiHandler'
Set the executable: %windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll
Now, your config entries above should kick in when an HTTP OPTIONS verb is sent.
Alternatively you can respond to the HTTP OPTIONS verb in your BeginRequest method.
protected void Application_BeginRequest(object sender,EventArgs e)
{
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "*");
if(HttpContext.Current.Request.HttpMethod == "OPTIONS")
{
//These headers are handling the "pre-flight" OPTIONS call sent by the browser
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE");
HttpContext.Current.Response.AddHeader("Access-Control-Allow-Headers", "Content-Type, Accept");
HttpContext.Current.Response.AddHeader("Access-Control-Max-Age", "1728000" );
HttpContext.Current.Response.End();
}
}
I can't post comments so I have to put this in a separate answer, but it's related to the accepted answer by Shah.
I initially followed Shahs answer (thank you!) by re configuring the OPTIONSVerbHandler in IIS, but my settings were restored when I redeployed my application.
I ended up removing the OPTIONSVerbHandler in my Web.config instead.
<handlers>
<remove name="OPTIONSVerbHandler"/>
</handlers>