OK! Here's the answer (I hope)...
In my Web API project I add a NuGet reference to
Microsoft.Aspnet.WebApi.Cors
<https://www.nuget.org/packages/Microsoft.AspNet.WebApi.Cors>. You can now
add the [EnableCors(...)] attribute to controller methods, or for my simple
testing convenience I added this for a global change:
config.EnableCors(new EnableCorsAttribute("*", "*", "*")));
This makes magic happen so each preflight OPTIONS request is silently
handled. You can see the negotiation in Fiddler and the rest of the API
calls happen nicely.
So it's nice that someone has already considered all the plumbing to make
CORS work in our web projects. The hard part as usual was finding it
amongst all the clutter, arguments and documentation. Although, we are
still at the mercy of various brands and versions of browsers to behave
correctly with the above.
*Greg*
On 28 August 2015 at 07:51, Greg Keogh <[email protected]> wrote:
> The Linux guys are calling my service using $http.get and they asked me to
> put all of these in my response:
>
> Access-Control-Allow-Origin: *
> Access-Control-Allow-Headers: X-Requested-With
> Access-Control-Allow-Headers: Content-Type
> Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS
>
> This got us through the first call, but in the second call they have to
> add a custom request header containing a login token from the first call,
> and that resulted in an OPTIONS request, which left me really confused.
>
> However, this morning I have already learned why that OPTIONS request was
> generated. This guy
> <https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS>
> explains what what I'm seeing is a "preflight" request. I'm still reading
> ... I'm not sure I can completely bypass SOP by using CORS response
> headers, or if I need to handle preflight requests as well.
>
> *Greg*
>
