浏览器实施同源策略的方式有很大差异吗？

Question

我的主页上有一个表单，设置为通过XHR POST提交到网址https://mydomain.com/send_sms。

当我在Internet Explorer（http://mydomain.com）中访问主页的非SSL版本时提交表格，没有任何反应。在Webkit控制台中，我收到一条有用的错误，指出Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

然而，在Firefox 13中，请求明确提交＆amp; a返回200 OK，但响应正文为空。此外，服务器端操作（发送SMS）实际上是由Firefox请求触发的，而不是其他浏览器触发的。

我一直认为同源策略甚至拒绝发送请求，但也许是浏览器从不允许的响应中接收数据？

任何人都知道这是否是Mozilla在实施（甚至可能是疏忽）方面的一个有目的的差异？

Answer 1

首先，http://example.com和https://example.com是不同的来源。对于XHR Level 1，这意味着，不允许跨源请求。

但是对于支持XHR (Level 2)（服务器和客户端都支持！）的当前CORS，跨域请求可以是

• simple cross-orgin request，如果

  • 请求方法为GET，HEAD或POST，
  • 请求标头字段均不是Accept，Accept-Language，Content-Language或Content-Type以及
  之外的字段
  • 未设置预检标志

  或

• a cross-origin request that requires a preflight，否则。

对于简单的跨源请求，允许浏览器发送请求。但是当收到回复时，它需要check whether the server allows to share the resource。这是检查Access-Control-Allow-Origin标头字段和其他Access-Control-*响应标头字段的位置。并且只有在通过此检查时，浏览器才允许脚本读取响应。

对于其他跨源请求，需要进行预检以与服务器协商在实际请求中允许发送哪些信息。此预检请求基本上是OPTIONS请求，告知服务器实际请求将包含哪些内容（请求方法和标头字段）。然后服务器可以决定是否允许这样的请求。

在您的情况下，观察到的行为可能有多种原因。我猜你的 send_sms 脚本不是support the server side part for CORS。

Answer 2

应禁止发送数据，例如接收数据。如果在这个页面上有一些恶意JS并且它正在向每个随机服务器提交每个击键怎么办？在这种情况下，发送比接收更加邪恶（除此之外，这实际上可以通过请求具有查询字符串的图像或脚本等资源来实现，因为它们不受同一原始策略的约束）。 p>

我在过去遇到了一些细微的差别，但这通常与传统的IE有关。

对我而言，firefox差异是一个错误（提供vanilla安装有这个特性）。不同的协议（HTTP与HTTPS）相当于不同的来源，即使同一协议上的子域被认为是不同的来源，因此FF13绝对不应该发出AJAX请求。

您没有设置CORS（跨源资源共享），FF13是您测试过的唯一支持它的浏览器吗？