I have a web service which I host on my machine. I use Windows 7 and IIS 7.5.
Problem: When the client tries to consume the web service, he/she ge
Ahh -- I've finally found a solution to my CORS on IIS hell. This was one of the problems that popped up during my solution finding.
The correct answer is aliostad's -- The problem comes from the fact that for some solutions for implementing the 'OPTIONS' verb, removal of the mapping of that verb to the ProtocolSupportModule was recommended. Or perhaps someone just cleaned out the unnecessary mappings, etc. This left no handler for OPTIONS.
I'm not an expert on exactly what happens behind the scenes, but it seems that IIS makes sure there is a potential handler for the request long before the Application_BeginRequest event is fired, this despite their sequence diagrams:
https://msdn.microsoft.com/en-us/library/bb470252.aspx
So a 405 status is returned without ever executing your module. What was being sent to the server is for example:
OPTIONS http://www.example.com/path/mypage.aspx
So IIS is looking for a handler for *.aspx that accepts the OPTIONS verb. If you look at your default applicationHost.config file, you'll see, for example:
I had just done the following in my web.config to make IIS stop returning status 200 noops:
So, trying it at first, and concluding that this is what was needed, I added the following to my web.config:
Note that the replacements match what is in applicationHost.config, except with the extra OPTIONS verb added to each line.
For those of you who are using routing (MVC or webapi for example):
Lastly, I'm no IIS expert -- perhaps there is a different more efficient way to handle the OPTIONS verb for CORS (more specifically, allow your CORS handler to work without the 'custom header' partial solution, I'm open to those solutions.