我的主頁上有一個表單，通過XHR POST提交到URL 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但是，請求明確提出&一個回報200 OK，但響應正文爲空。此外，服務器端動作（發送短信）實際上是由Firefox請求觸發的，而不是其他瀏覽器觸發的。
我一直認爲即使發送請求也拒絕同源策略，但也許瀏覽器從響應中接收不允許的數據？
任何人都知道這是否是Mozilla實現（或者甚至可能是疏忽）的有目的的區別？
首先，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，和或
對於簡單的跨源請求，允許瀏覽器發送請求。但收到回覆時，需要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。
很好的答案！我對CORS的瞭解很有限，因此對有更深入理解的人可以有所瞭解 – WickyNilliams
應該禁止發送數據，就像接收數據一樣。如果在這個頁面上有一些惡意JS，並且它將每個按鍵提交給某個隨機服務器，該怎麼辦？在這種情況下，發送比接收更加惡毒（順便說一下，實際上可以通過請求像圖像或腳本之類的資源和查詢字符串來實現，因爲它們不受同一起源策略的限制）。
我在過去遇到過細微的差異，但通常是使用舊版IE。
對我來說，Firefox的差異是一個錯誤（提供一個香草安裝有這個特點）。一個不同的協議（HTTP vs HTTPS）相當於一個不同的起源，即使同一個協議中的子域被認爲是不同的來源，所以FF13應該不會發出AJAX請求。
您沒有碰巧設置了CORS（跨源資源共享），並且FF13是您測試過的唯一支持它的瀏覽器？
CORS必須發送請求看看這個響應是否包含一個'Access-Control-Allow-Origin'頭部？因此，請求已發出，服務器可以根據需要處理它，但它只是不會將響應數據返回給瀏覽器，除非它將該標題與其一起發送。 – Paulpro
這是一個Rails應用程序，這個表單通過jQuery使用了Rails的開箱即用的'data-remote'功能。沒有CORS設置，響應中沒有'Access-Control-Allow-Origin'標頭（儘管有一個'Set-Cookie'標頭，這看起來很麻煩）。版本13是我測試過的唯一的Firefox。 –
任何特定於rails/Ruby的應用程序都不應該在瀏覽器級別執行相同的源策略。所以你的技術堆棧應該是無足輕重的。如果你不是自己設置一個cookie，'set-cookie'頭可能是一個會話cookie。 – WickyNilliams
我確實可以在Firefox 13中進行交叉協議請求（至少http-> https），但不能在谷歌瀏覽器中進行。我在一臺甚至不發送CORS頭文件的服務器上進行了測試。 – Esailija
相關：http://stackoverflow.com/questions/10212071/jquery-ajax-post-to-rails-3-2-2-not-allowed-by-access-control-allow-origin –