I'm trying to make a cross-domain XHR call from my MVC app to my Web API service using VS2012 RC. I've set up a CORS DelegatingHandler as per
Carlos's blog entry that will append the necessary ACAO header to the response headers. I've noticed that Chrome and Firefox are unable to send preflighted XHR requests to my Web API service. Tracing the network calls showed that Chrome and FF both send
the OPTIONS request to IIS 7.5 (or 7.5 express, makes no difference) and the response that comes back from IIS does not contain the ACAO headers. Breakpoints in the CorsHandler show that it never gets called for the OPTIONS request.
Since FF and Chrome don't receive the ACAO headers, they believe this is insecure cross-domain scripting and refuse to send the request. IE9 does not make the preflighted OPTIONS call and skips straight to the GET, which does get handled by CorsHandler
and gets the proper ACAO headers. So IE9 never sees the problem. If I switch over from IIS7.5 to Cassini, everything works great with FF and Chrome as Cassini returns the ACAO headers in the OPTIONS response.
Am I missing something obvious or is this just an oversight in IIS7.5? It seems like there's no way to support preflighted XHR requests with IIS7.5 and instead we have to make sure no cross-domain XHRs ever get escalated to preflighting by the browsers.
No offence to Carlos, but his CORS implementation is lacking. I built a standards compliant implementation into Thinktecture.IdentityModel. Blog post here:
I can't really speak to what it lacks or doesn't lack as far as other functionality of CORS, but I really just need ACAO headers added into my Web API responses and Carlos's method does the trick, except for the fact that IIS 7.5 doesn't pass OPTIONS requests
through to the message handlers. This seems like an oversight to me and I'm still wondering if this is expected behavior or an issue with IIS 7.5.
Yea, but my point is that usually you need more than just ACAO if you've gotten to a pre-flight request (meaining OPTIONS). If you're returning data or sending data then you also need headers (think Accept and Content-Type). You also need to emit which methods
you allow. I fyou care about cookies (which you might not if you're doing WCF) then there's that too.
In any event, I think your problem is that the HTTP handler you're using for WCF isn't allowing OPTIONS. Also, you might be running into WebDAV - I forget if it also handles OPTIONS but if it does it tends to get the request first and then eclipses your
code. So the 2 things I had to do in IIS to recieve REST requests was to 1) Uninstall WebDAV, 2) map the options you want on the HTTP handler you're using (so for me this was the extension-less http handler for PUT, DELETE and OPTIONS).
mikeycooper
0 Points
2 Posts
CORS issues with IIS 7.5 and DelegatingHandlers (Web API service)
Aug 10, 2012 02:25 AM|LINK
I'm trying to make a cross-domain XHR call from my MVC app to my Web API service using VS2012 RC. I've set up a CORS DelegatingHandler as per Carlos's blog entry that will append the necessary ACAO header to the response headers. I've noticed that Chrome and Firefox are unable to send preflighted XHR requests to my Web API service. Tracing the network calls showed that Chrome and FF both send the OPTIONS request to IIS 7.5 (or 7.5 express, makes no difference) and the response that comes back from IIS does not contain the ACAO headers. Breakpoints in the CorsHandler show that it never gets called for the OPTIONS request.
Since FF and Chrome don't receive the ACAO headers, they believe this is insecure cross-domain scripting and refuse to send the request. IE9 does not make the preflighted OPTIONS call and skips straight to the GET, which does get handled by CorsHandler and gets the proper ACAO headers. So IE9 never sees the problem. If I switch over from IIS7.5 to Cassini, everything works great with FF and Chrome as Cassini returns the ACAO headers in the OPTIONS response.
Am I missing something obvious or is this just an oversight in IIS7.5? It seems like there's no way to support preflighted XHR requests with IIS7.5 and instead we have to make sure no cross-domain XHRs ever get escalated to preflighting by the browsers.
BrockAllen
All-Star
27522 Points
4901 Posts
MVP
Re: CORS issues with IIS 7.5 and DelegatingHandlers (Web API service)
Aug 10, 2012 02:27 AM|LINK
No offence to Carlos, but his CORS implementation is lacking. I built a standards compliant implementation into Thinktecture.IdentityModel. Blog post here:
http://brockallen.com/2012/06/28/cors-support-in-webapi-mvc-and-iis-with-thinktecture-identitymodel/
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/
mikeycooper
0 Points
2 Posts
Re: CORS issues with IIS 7.5 and DelegatingHandlers (Web API service)
Aug 10, 2012 02:40 AM|LINK
I can't really speak to what it lacks or doesn't lack as far as other functionality of CORS, but I really just need ACAO headers added into my Web API responses and Carlos's method does the trick, except for the fact that IIS 7.5 doesn't pass OPTIONS requests through to the message handlers. This seems like an oversight to me and I'm still wondering if this is expected behavior or an issue with IIS 7.5.
BrockAllen
All-Star
27522 Points
4901 Posts
MVP
Re: CORS issues with IIS 7.5 and DelegatingHandlers (Web API service)
Aug 10, 2012 02:51 AM|LINK
Yea, but my point is that usually you need more than just ACAO if you've gotten to a pre-flight request (meaining OPTIONS). If you're returning data or sending data then you also need headers (think Accept and Content-Type). You also need to emit which methods you allow. I fyou care about cookies (which you might not if you're doing WCF) then there's that too.
In any event, I think your problem is that the HTTP handler you're using for WCF isn't allowing OPTIONS. Also, you might be running into WebDAV - I forget if it also handles OPTIONS but if it does it tends to get the request first and then eclipses your code. So the 2 things I had to do in IIS to recieve REST requests was to 1) Uninstall WebDAV, 2) map the options you want on the HTTP handler you're using (so for me this was the extension-less http handler for PUT, DELETE and OPTIONS).
HTH
DevelopMentor | http://www.develop.com
thinktecture | http://www.thinktecture.com/