Question

After running into the famous Access-Control-Allow-Origin problem while testing ServiceStack, I did a bunch of reading on CORS to better understand the problem. I also came across this very helpful SO question.

However, the solutions there did not work for me. I tried including the CorsFeature plugin and also setting the endpoint config manually, but after trying both ways I saw that the response headers coming back from the server did not include any of my Access-Control-Allow-* headers, hence the problem remained.

I tried another solution which ended up working for me (through with some other problems that aren’t relevant here). I added the following to my service’s web.config:

<system.webServer>
  [...snip...]
  <httpProtocol>
    <customHeaders>
      <clear />
      <add name="Access-Control-Allow-Origin" value="*" />
      <add name="Access-Control-Allow-Headers" value="Content-Type" />
      <add name="Access-Control-Allow-Methods" value="GET, POST, PUT, DELETE, OPTIONS" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

(Other readers, note that this only works on IIS7+. See http://enable-cors.org/ to learn more about enabling CORS on other servers)

My question is: why was I able to get my headers written using this web.config method, but not by using ServiceStack’s built-in CORS support? Is there a config setting I’m missing somewhere?

Answer 1

I was reviewing more of @mythz‘s SO answers and came across this one. For reasons I don’t fully understand (yet), adding in that request filter (as well as the CorsFeature plugin) allowed everything to work as expected. I don’t get an error on my preflight OPTIONS request, or any origin errors on my GETs and POSTs.

So, in short, my final solution was to copy the code from mythz’s answer in that post into my AppHost.Configure(), and remove my web.config custom headers. (Before I removed my custom headers from my web.config, I was actually getting my headers doubled up!)