4

在测试 ServiceStack 时遇到了著名的Access-Control-Allow-Origin问题后，我对CORS进行了大量阅读以更好地理解问题。我也遇到了这个非常有用的 SO question。

但是，那里的解决方案对我不起作用。我尝试包含CorsFeature插件并手动设置端点配置，但是在尝试了两种方式后，我发现从服务器返回的响应标头不包含我的任何Access-Control-Allow-*标头，因此问题仍然存在。

我尝试了另一种最终对我有用的解决方案（通过一些与此处无关的其他问题）。我在我的服务的 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>

（其他读者请注意，这只适用于 IIS7+。请参阅http://enable-cors.org/了解有关在其他服务器上启用 CORS 的更多信息）

我的问题是：为什么我能够使用这个 web.config 方法编写我的标头，而不是使用 ServiceStack 的内置 CORS 支持？是否有我在某处缺少的配置设置？

4

1 回答 1

2

我正在查看更多@mythz的 SO 答案并遇到了这个。由于我（还）不完全理解的原因，添加该请求过滤器（以及 CorsFeature 插件）允许一切按预期工作。我的预检 OPTIONS 请求没有错误，我的 GET 和 POST 也没有任何来源错误。

所以，简而言之，我的最终解决方案是将该帖子中的 mythz 答案中的代码复制到我的AppHost.Configure()中，并删除我的 web.config 自定义标头。（在我从 web.config 中删除我的自定义标头之前，我实际上将我的标头加倍了！）

于 2013-02-06T20:07:26.077 回答