jQuery $ .ajax (), $ .post отправляет «OPTIONS» как REQUEST_METHOD в Firefox

Я использовал следующий код на стороне Django для интерпретации запроса OPTIONS и для установки необходимых заголовков Access-Control. После этого мои кросс-доменные запросы от Firefox начали работать. Как говорилось ранее, браузер сначала отправляет запрос OPTIONS, а затем сразу же после этого POST/GET

def send_data(request):
    if request.method == "OPTIONS": 
        response = HttpResponse()
        response['Access-Control-Allow-Origin'] = '*'
        response['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS'
        response['Access-Control-Max-Age'] = 1000
        # note that '*' is not valid for Access-Control-Allow-Headers
        response['Access-Control-Allow-Headers'] = 'origin, x-csrftoken, content-type, accept'
        return response
    if request.method == "POST":
        # ... 

Изменить: похоже, что по крайней мере в некоторых случаях вам также необходимо добавить те же заголовки Access-Control в фактический ответ. Это может быть немного запутанным, так как запрос кажется успешным, но Firefox не передает содержимое ответа на Javascript.

Эта статья статьи разработчиков mozilla описывает различные сценарии междоменных запросов. В статье, как представляется, указывается, что запрос POST с типом контента "application/x-www-form-urlencoded" должен быть отправлен как "простой запрос" (без запроса "preflight" OPTIONS). Однако я обнаружил, что Firefox отправил запрос OPTIONS, хотя мой POST был отправлен с этим типом контента.

Мне удалось выполнить эту работу, создав обработчик запросов параметров на сервере, который установил заголовок ответа "Access-Control-Allow-Origin" на "*". Вы можете быть более ограничительным, установив его на что-то конкретное, например 'http://someurl.com'. Кроме того, я прочитал, что, предположительно, вы можете указать список из нескольких источников, но я не мог заставить это работать.

Как только Firefox получит ответ на запрос OPTIONS с допустимым значением "Access-Control-Allow-Origin", он отправит запрос POST.

Я исправил эту проблему, используя полностью основанное на Apache решение. В моем vhost/htaccess я помещаю следующий блок:

# enable cross domain access control
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS"

# force apache to return 200 without executing my scripts
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* / [R=200,L]

Вам может не понадобиться последняя часть, в зависимости от того, что произойдет, когда Apache выполнит вашу цель script. Кредит отправляется дружественному файлу ServerFault для последней части.

Этот PHP в верхней части отклика script, похоже, работает. (С Firefox 3.6.11. Я еще не проверил много тестов.)

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST, GET, OPTIONS');
header('Access-Control-Max-Age: 1000');
if(array_key_exists('HTTP_ACCESS_CONTROL_REQUEST_HEADERS', $_SERVER)) {
    header('Access-Control-Allow-Headers: '
           . $_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']);
} else {
    header('Access-Control-Allow-Headers: *');
}

if("OPTIONS" == $_SERVER['REQUEST_METHOD']) {
    exit(0);
}

У меня была такая же проблема с отправкой запросов на карты google, и решение довольно просто с jQuery 1.5 - для использования dataType dataType: "jsonp"

Я просматривал источник 1.3.2, при использовании JSONP запрос выполняется путем динамического создания элемента SCRIPT, который проходит мимо политики браузера с одинаковым доменом. Естественно, вы не можете сделать запрос POST с помощью элемента SCRIPT, браузер будет извлекать результат с помощью GET.

Когда вы запрашиваете вызов JSONP, элемент SCRIPT не генерируется, потому что он делает это только тогда, когда для вызова типа AJAX установлено значение GET.

http://dev.jquery.com/ticket/4690

Culprit - это предполетный запрос с использованием метода OPTIONS

Для методов HTTP-запросов, которые могут вызывать побочные эффекты для пользовательских данных (в частности, для HTTP-методов, отличных от GET или для использования POST с определенными типами MIME), спецификация требует, чтобы браузеры "предваряли" запрос, поддерживая поддержку методы с сервера с помощью метода запросов HTTP OPTIONS, а затем, после "утверждения" с сервера, отправка фактического запроса с помощью метода HTTP-запроса.

Веб-спецификация относится к: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Я решил проблему, добавив следующие строки в Nginx conf.

    location / {
               if ($request_method = OPTIONS ) {
                   add_header Access-Control-Allow-Origin  "*";
                   add_header Access-Control-Allow-Methods "POST, GET, PUT, UPDATE, DELETE, OPTIONS";
                   add_header Access-Control-Allow-Headers "Authorization";
                   add_header Access-Control-Allow-Credentials  "true";
                   add_header Content-Length 0;
                   add_header Content-Type text/plain;
                   return 200;
               }
    location ~ ^/(xxxx)$ {
                if ($request_method = OPTIONS) {
                    rewrite ^(.*)$ / last;
                }
    }

У нас возникла проблема с ASP.Net. Наш IIS возвращал внутреннюю ошибку сервера при попытке выполнить jQuery $.post, чтобы получить некоторый html-контент из-за того, что PageHandlerFactory был ограничен, чтобы отвечать только GET,HEAD,POST,DEBUG глаголам. Таким образом, вы можете изменить это ограничение, добавив в список глагол "ОПЦИИ" или выбрав "Все глаголы"

Вы можете изменить это в своем диспетчере IIS, выбрав свой веб-сайт, затем выбрав "Сопоставление обработчиков", дважды щелкните в файле PageHandlerFactory для *.apx по мере необходимости (мы используем интегрированный пул приложений с фреймворком 4.0). Нажмите "Ограничения запроса", затем перейдите в раздел "Глаголы" и примените свои изменения.

Теперь наш запрос $.post работает как ожидалось:)

Проверьте, содержит ли ваша форма action URL-адрес части www домена, а исходная страница, которую вы открыли, просматривается без www.

Обычно делается для канонических сообщений.

Я боролся несколько часов, прежде чем наткнуться на эту статью и нашел намек на Cross Domain.

Кажется, что если o.url = 'index.php' и этот файл существует, это нормально и возвращает сообщение об успешном завершении в консоли. Он возвращает ошибку, если я использую url: http://www.google.com

Если вы выполняете почтовый запрос, почему бы не использовать метод $. post:

$.post("test.php", { func: "getNameAndTime" },
    function(data){
        alert(data.name); // John
        console.log(data.time); //  2pm
    }, "json");

Это намного проще.

Я опубликовал четкий пример того, как решить эту проблему, если вы управляете кодом сервера домена, на который вы отправляете POST. Этот ответ затрагивается в этой теме, но это более четко объясняет это ИМО.

Как отправить запрос POST для междоменной области через JavaScript?

Решение этого:

• use dataType: json
• добавить &callback=? в ваш URL

это работало при вызове Facebook API и с Firefox. Firebug использует GET вместо OPTIONS с указанными выше условиями (оба из них).

Еще одна возможность обойти эту проблему - использовать прокси script. Этот метод описан для пример здесь

У меня уже есть эта обработка кода, моя ситуация с корсом в php:

header( 'Access-Control-Allow-Origin: '.CMSConfig::ALLOW_DOMAIN );
header( 'Access-Control-Allow-Headers: '.CMSConfig::ALLOW_DOMAIN );
header( 'Access-Control-Allow-Credentials: true' );

И он работал нормально локально и удаленно, но не для загрузки при удалении.

Что-то случилось с apache/php ИЛИ моим кодом, я не стал искать его, когда вы запрашиваете OPTIONS, он возвращает мой заголовок с правилами cors, но с результатом 302. Поэтому мой браузер не распознает приемлемую ситуацию.

Что я сделал, основываясь на ответе @Mark McDonald, просто поместил этот код после моего заголовка:

if( $_SERVER['REQUEST_METHOD'] === 'OPTIONS' )
{
    header("HTTP/1.1 202 Accepted");
    exit;
}

Теперь при запросе OPTIONS он просто отправит заголовок и результат 202.

Я использовал прокси-url для решения аналогичной проблемы, когда я хочу отправить данные в мой apache solr, размещенный на другом сервере. (Это может быть не идеальный ответ, но он решает мою проблему.)

Следуйте этому URL-адресу: Используя режим-переписывание для проксирования, я добавляю эту строку в свой httpd.conf:

 RewriteRule ^solr/(.*)$ http://ip:8983/solr$1 [P]

Поэтому я могу просто отправить данные в /solr вместо публикации данных в http://ip:8983/solr/ *. Затем он будет размещать данные в одном и том же источнике.

Попробуйте добавить следующее:

dataType: "json",
ContentType: "application/json",
data: JSON.stringify({"method":"getStates", "program":"EXPLORE"}),  

Вам нужно выполнить некоторую работу на стороне сервера. Я вижу, что вы используете PHP на стороне сервера, но решение для веб-приложения .NET находится здесь: Невозможно установить тип содержимого в 'application/json' в jQuery.ajax

Сделайте то же самое в PHP script, и он будет работать. Просто: при первом запросе браузер запрашивает сервер, если разрешено отправлять такие данные с таким типом, а второй запрос является правильным/разрешенным.

 function test_success(page,name,id,divname,str)
{ 
 var dropdownIndex = document.getElementById(name).selectedIndex;
 var dropdownValue = document.getElementById(name)[dropdownIndex].value;
 var params='&'+id+'='+dropdownValue+'&'+str;
 //makerequest_sp(url, params, divid1);

 $.ajax({
    url: page,
    type: "post",
    data: params,
    // callback handler that will be called on success
    success: function(response, textStatus, jqXHR){
        // log a message to the console
        document.getElementById(divname).innerHTML = response;

        var retname = 'n_district';
        var dropdownIndex = document.getElementById(retname).selectedIndex;
        var dropdownValue = document.getElementById(retname)[dropdownIndex].value;
        if(dropdownValue >0)
        {
            //alert(dropdownValue);
            document.getElementById('inputname').value = dropdownValue;
        }
        else
        {
            document.getElementById('inputname').value = "00";
        }
        return;
        url2=page2; 
        var params2 = parrams2+'&';
        makerequest_sp(url2, params2, divid2);

     }
});         
}

У меня была аналогичная проблема с попыткой использовать API Facebook.

Единственный contentType, который не отправил запрос Preflighted, казалось, был просто текстовым/простым... не остальные параметры, упомянутые в mozilla здесь

• Почему это единственный браузер, который делает это?
• Почему Facebook не знает и не принимает запрос перед полетом?

FYI: вышеупомянутый Moz doc предлагает, чтобы заголовки X-Lori должны запускать запрос с предварительным освещением... это не так.

Попробуйте добавить параметр:

dataType: "json"

Можете ли вы попробовать это без

contentType:application/x-www-form-urlencoded

Обратите внимание:

JSONP поддерживает только метод запроса GET.

* Отправить запрос от firefox: *

$.ajax({
   type: 'POST',//<<===
   contentType: 'application/json',
   url: url,
   dataType: "json"//<<=============
    ...
});

Выше запроса отправьте ОПЦИИ (в то время как == > введите: "POST" )!!!!

$.ajax({
    type: 'POST',//<<===
    contentType: 'application/json',
    url: url,
    dataType: "jsonp"//<<==============
    ...
});

Но выше запроса отправьте GET (в то время как == > введите: "POST" )!!!!

Когда вы находитесь в "междоменной связи", обратите внимание и будьте осторожны.