AJAX в настройках отправки Chrome Вместо GET/POST/PUT / DELETE?
Я работаю над внутренним веб-приложением на работе. В IE10 запросы работают нормально, но в Chrome все запросы AJAX (которых много) отправляются с использованием опций вместо любого определенного метода, который я ему даю. Технически мои запросы - это " кросс-домен."Сайт обслуживается на localhost: 6120, а служба, к которой я делаю запросы AJAX, находится на 57124. эта закрытая ошибка jquery определяет проблему, но не реальное исправление.
что я могу сделать, чтобы использовать правильный http метод в ajax-запросах?
Edit:
это в загрузке документа каждой страницы:
jQuery.support.cors = true;
и каждый AJAX строится аналогично:
var url = 'http://localhost:57124/My/Rest/Call';
$.ajax({
url: url,
dataType: "json",
data: json,
async: true,
cache: false,
timeout: 30000,
headers: { "x-li-format": "json", "X-UserName": userName },
success: function (data) {
// my success stuff
},
error: function (request, status, error) {
// my error stuff
},
type: "POST"
});
9 ответов:
Chrome предварительно высвечивает запрос на поиск CORS заголовки. Если запрос приемлем, то он отправит реальный запрос. Если вы делаете этот кросс-домен, вам просто придется иметь дело с ним или же найти способ сделать запрос не кросс-доменным. Вот почему ошибка jQuery была закрыта как won't-fix. Это сделано специально.
в отличие от простых запросов (см. выше), "preflighted" просит первый отправить HTTP-запрос с помощью метода OPTIONS к ресурсу на другой домен, чтобы определить, является ли фактический запрос безопасным посылать. Межсайтовые запросы предварительно подсвечиваются таким образом, поскольку они могут имеют последствия для пользовательских данных. В частности, запрос предварительный свет, если:
- он использует методы, отличные от GET, HEAD или POST. Кроме того, если POST используется для отправки данных запроса с типом контента, отличным от применение/х-www-формы-urlencoded, multipart/данные формы, или обычный текст, например, если сообщение запрос отправляет полезную нагрузку XML на сервер с помощью application / xml или text / xml, затем запрос предварительно подсвечивается.
- он устанавливает пользовательские заголовки в запросе (например, запрос использует заголовок, такой как X-PINGOTHER)
исходя из того, что запрос не отправляется на порт по умолчанию 80/443 этот вызов Ajax автоматически считается запросом ресурса кросс-происхождения (CORS), что другими словами означает, что запрос автоматически выдает запрос опций, который проверяет заголовки CORS на стороне сервера/сервлета.
это происходит, даже если вы установите
crossOrigin: false;или даже если опустить ее.
причина просто в том, что
localhost != localhost:57124. Попробуйте отправить его только вlocalhostбез порта-это не удастся, потому что запрошенная цель не будет доступна,однако обратите внимание, что если доменные имена равны запрос отправляется без запроса параметров перед отправкой.
Я согласен с Кевином Б, отчет об ошибке все сказано. Это звучит, как вы пытаетесь сделать кросс-доменные AJAX-вызовы. Если вы не знакомы с той же политикой происхождения, вы можете начать здесь: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript.
Если это не предназначено для междоменного вызова ajax, попробуйте сделать свой целевой url-адрес относительным и посмотреть, исчезнет ли проблема. Если вы действительно отчаянно смотрите в JSONP, но остерегайтесь, хаос скрывается. Там действительно не намного больше мы можем сделать, чтобы помочь вам.
если можно передать параметры через обычный GET / POST с другим именем и пусть ваш код на стороне сервера обрабатывает его.
у меня была аналогичная проблема с моим собственным прокси-сервером для обхода CORS, и я получил ту же ошибку POST - >OPTION в Chrome. Это был
Authorizationзаголовок в моем случае ("x-li-format"и"X-UserName"здесь в вашем случае.) Я закончил тем, что передал его в фиктивном формате (например,AuthorizatinJackв GET) и я изменил код для моего прокси, чтобы превратить его в заголовок при вызове назначение. Вот он в PHP:if (isset($_GET['AuthorizationJack'])) { $request_headers[] = "Authorization: Basic ".$_GET['AuthorizationJack']; }
в моем случае я вызываю API, размещенный AWS (API Gateway). Ошибка произошла, когда я попытался вызвать API из домена, отличного от собственного домена API. Поскольку я являюсь владельцем API, я включил CORS для тестовой среды, как описано в Документация Amazon.
в производстве эта ошибка не произойдет, так как запрос и api будут находиться в одном домене.
Надеюсь, это поможет!
Как ответил by @Dark Falcon, I просто справился с этим.
в моем случае, я использую узел.JS-сервер и создание сеанса, если он не существует. Поскольку метод OPTIONS не содержит сведений о сеансе, он в конечном итоге создал новый сеанс для каждого запроса метода POST.
Итак, в моей подпрограмме приложения для создания-сеанса-если-не-существует, я просто добавил проверку, чтобы узнать, является ли метод
OPTIONS, и если да, то просто пропустите создание сеанса часть:app.use(function(req, res, next) { if (req.method !== "OPTIONS") { if (req.session && req.session.id) { // Session exists next(); }else{ // Create session next(); } } else { // If request method is OPTIONS, just skip this part and move to the next method. next(); } }
запросы"preflighted" сначала отправляют HTTP-запрос методом OPTIONS на ресурс в другом домене, чтобы определить, является ли фактический запрос безопасным для отправки. Кросс-сайтовые запросы
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
рассмотрите возможность использования axios
axios.get( url, { headers: {"Content-Type": "application/json"} } ).then( res => { if(res.data.error) { } else { doAnything( res.data ) } }).catch(function (error) { doAnythingError(error) });У меня была эта проблема с помощью fetch и axios работал отлично.