Are there substantial differences in the way browsers implement the same-origin policy?

Question

I have a form on my homepage that is set up to submit via XHR POST to the URL https://mydomain.com/send_sms.

When I visit the non-SSL version of the homepage in Internet Explorer (http://mydomain.com) & submit the form, nothing happens. In Webkit console, I receive a helpful error stating Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

In Firefox 13 however, the request clearly submits & a returns a 200 OK, though the response body is blank. Furthermore, the server-side action (sending an SMS) is in fact triggered by the Firefox request but not the other browsers.

I always thought the same-origin policy denied even the sending of the request, but perhaps it's the browser receiving data from the response that's disallowed?

Anyone know if this is a purposeful difference in implementation (or possibly even an oversight) by Mozilla?

Answer 1

First of all, http://example.com and https://example.com are different origins. For XHR Level 1 this would mean, cross-origin requests are not allowed.

But for the current XHR (Level 2), which supports cross-origin requests when CORS is supported (by both server and client!), a cross-origin request can either be

• a simple cross-orgin request, if

  • the request method is GET, HEAD, or POST, and
  • none of the request header fields is one other than Accept, Accept-Language, Content-Language, or Content-Type, and
  • the preflight flag is not set

  or

• a cross-origin request that requires a preflight, otherwise.

For simple cross-origin requests, the browser is allowed to send the request. But when the response is received, it needs to check whether the server allows to share the resource. This is where the Access-Control-Allow-Origin header field and other Access-Control-* response header fields are checked. And only if this check is passed, the browser allows the script to read the response.

For other cross-origin requests, a preflight is required to negotiate with the server what information is allowed to be sent in the actual request. This preflight request is basically a OPTIONS request telling the server what the actual request will contain (request method and header fields). Then the server can decide whether it allows such request or not.

In your case, the observed behavior can have multiple reasons. I guess your send_sms script just doesn’t support the server side part for CORS.