2016-09-03 2 views
1

Рассмотрите очень простой пример использования XMLHttpRequest.Почему браузер разрешает xorigin POST, но не PUT?

Следующие сообщения должным образом (вы можете увидеть его на вкладке сети или направляя ваш браузер http://requestb.in/yckncpyc), хотя он выдает предупреждение на консоль

XMLHttpRequest не может загрузить http://requestb.in/yckncpyc. Нет Заголовок «Access-Control-Allow-Origin» присутствует на запрошенном ресурсе . Поэтому исходный 'null' не допускается.

const method = "POST" 
 
const req = new XMLHttpRequest() \t 
 
req.open(method, 'http://requestb.in/yckncpyc') 
 
req.send("foobar") 
 
console.log("sent") 
 
req.addEventListener('load', function() { console.log(req.status, req.response) })

Конечно. Я понимаю. Я не понимаю, почему просто изменение глагола, используемого для PUT, приводит к чему-то совершенно другому. Отправлен запрос является OPTIONS предполетной запрос и выводит

XMLHttpRequest не может загрузить http://requestb.in/yckncpyc. Ответ на предполетный запрос не проходит проверку контроля доступа: Нет Заголовок «Access-Control-Allow-Origin» присутствует на запрошенном ресурсе . Поэтому исходный 'null' не допускается.

const method = "PUT" 
 
const req = new XMLHttpRequest() \t 
 
req.open(method, 'http://requestb.in/yckncpyc') 
 
req.send("foobar") 
 
console.log("sent") 
 
req.addEventListener('load', function() { console.log(req.status, req.response) })

Почему браузер * рассматривать их по-разному? Это похоже на то, что было бы сделано для обеспечения безопасности, но это действительно не имеет смысла, так как злоумышленник всегда может использовать POST вместо PUT.

Так в чем же тут логика?

  • Пытался это в Chrome 52, Safari 9.1.2

ответ

1

GET, HEAD и POST запросов (с парой других ограничениями) может быть сделан перекрестным происхождение без дополнительной связи. Ответы не могут быть рассмотрены, но запросы разрешены.

Для чего-либо еще требуется предполетный запрос на проверку заголовков с целевого сайта, чтобы узнать, разрешен ли запрос.

Причина такой установки в том, что GET, HEAD и POST исторически разрешены в браузерах как естественная часть семантики HTML. Теги для скриптов и CSS и изображений выполняются с помощью запросов GET, а формы - POST. Поэтому, когда материал CORS был введен, они были допущены в предположении, что сайты не более уязвимы для простых запросов, подобных этому в мире XHR, тогда они были в более простом мире, отличном от XHR.

Разрешены простые запросы, и браузер просматривает заголовки ответов, чтобы решить, разрешено ли запрашивающему коду на странице перекрестного происхождения видеть контент ответа. Для других запросов браузер сначала отправляет запрос OPTIONS для проверки заголовков ответа CORS.Только если это выглядит нормально (то есть, если заголовки ответов содержат соответствующие заголовки «да, это нормально»), XHR будет разрешено продолжить.

+0

Хмм ... Где этот spec'ed? Я не вижу ничего об этом в спецификации (https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.6). И в этом отношении, что же такое рассуждение? –

+0

@GeorgeMauer answer extended - [вот статья MDN по этой теме.] (Https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS) – Pointy

+0

Хм ... так это один из тех вещи, а не спецификации, но браузеры все равно? –

Смежные вопросы