Существуют ли существенные различия в том, как браузеры реализуют политику одного и того же происхождения?

У меня есть форма на моей домашней странице, которая настроена для отправки через XHR POST по URL https://mydomain.com/send_sms.

Когда я перехожу к версии домашней страницы без SSL в Internet Explorer (http://mydomain.com) и отправлю форму, ничего не происходит. В консоли Webkit я получаю сообщение об ошибке Origin http://mydomain.com is not allowed by Access-Control-Allow-Origin.

В Firefox 13, однако, запрос явно отправляет и возвращает a 200 OK, хотя тело ответа пусто. Кроме того, действие на стороне сервера (отправка SMS) фактически инициируется запросом Firefox, но не другими браузерами.

Я всегда думал, что политика одного и того же происхождения отрицает даже отправку запроса, но, возможно, браузер получает данные от ответа, который запрещен?

Кто-нибудь знает, является ли это целенаправленной разницей в реализации (или, возможно, даже надзоре) Mozilla?

Ответы

Ответ 1

Прежде всего, http://example.com и https://example.com имеют различное происхождение. Для XHR Level 1 это означает, что запросы с кросс-началом не допускаются.

Но для текущего XHR (уровень 2), который поддерживает запросы с кросс-началом, когда CORS поддерживается (как сервером, так и клиентом!), запрос перекрестного происхождения может быть

a простой запрос cross-orgin, если
- метод запроса GET, HEAD или POST и
- ни одно из полей заголовка запроса не отличается от Accept, Accept-Language, Content-Language или Content-Type и
- флаг предполета не установлен
или
a запрос перекрестного происхождения, для которого требуется предполетная версия, в противном случае.

Для простых запросов перекрестного происхождения браузер может отправить запрос. Но когда ответ получен, ему необходимо проверить, разрешает ли сервер предоставлять ресурс. Здесь проверяется поле заголовка Access-Control-Allow-Origin и другие поля заголовка ответа Access-Control-*. И только если эта проверка передана, браузер позволяет script читать ответ.

Для других запросов с перекрестным происхождением требуется предварительный предлог для согласования с сервером, какая информация разрешена для отправки в реальном запросе. Этот запрос перед полетом в основном представляет собой запрос OPTIONS, указывающий серверу, что будет содержать фактический запрос (метод запроса и поля заголовка). Тогда сервер может решить, разрешает ли он такой запрос или нет.

В вашем случае наблюдаемое поведение может иметь несколько причин. Я предполагаю, что ваш send_sms script просто не поддерживает часть на стороне сервера для CORS.

Ответ 2

Отправка данных должна быть запрещена так же, как и прием, например. что, если на этой странице был какой-то вредоносный JS, и он подавал каждое нажатие клавиши на какой-то случайный сервер? В этом случае отправка более гнусная, чем прием (как в стороне, это может быть фактически достигнуто путем запроса ресурсов, таких как изображения или сценарии, с строкой запроса, поскольку они не подпадают под одну и ту же политику происхождения).

В прошлом я столкнулся с небольшими различиями, но обычно это было с устаревшим IE.

Для меня рассогласование firefox - ошибка (при условии, что установка vanilla имеет эту черту). Другой протокол (HTTP vs HTTPS) эквивалентен другому происхождению, даже поддомены в одном протоколе считаются разного происхождения, поэтому FF13 определенно не должен делать запрос AJAX.

У вас не установлено настроение ресурсов CORS (Cross-Origin Resource Sharing), а FF13 - единственный браузер, который вы тестировали для его поддержки?