Междоменный вызов AJAX для Luracast Restler API: ПОСТАВИТЬ и УДАЛИТЬ ВАРИАНТЫ отправки - Почему?

Я установил инфраструктуру Luracast Restler API и добился удивительного успеха во всем, кроме отправки PUT или DELETE между доменами. Приведенное ниже работает нормально, когда все на одном сервере, но когда я пересекаю домены, Firebug показывает PUT или GET как ВАРИАНТЫ, и он не найден на сервере. Я сбит с толку, как остановить отправку «OPTIONS» вместо PUT или DELETE.

$.ajax({
    url: url,
    type: 'PUT',
    data: "thename="+ $('#TheName').val(),
    success: function(xhr, status) {
        console.info(xhr);
    },
    error: function(xhr, status) {
        console.info(xhr.responseText);
    },
    complete: function(xhr, status) {
        $('#showResponse').val(xhr.responseText);
    }
});

Где-то в другом потоке я добавил в вывод Restler следующее:

    header('Access-Control-Allow-Origin: *');
    header('Access-Control-Allow-Methods: GET, POST, DELETE, PUT, OPTIONS');

PUT/GET/POST/DELETE на локальном хосте и в междоменном


cors post cross-domain put restler
person GDP    schedule 21.01.2013    source источник
comment
Это может помочь: stackoverflow.com/q/5750696/535275   -  person Scott Hunter    schedule 21.01.2013

Ответы (1)


arrow_upward
0
arrow_downward

У вас есть правильные заголовки ответа, но ваш сервер также должен отвечать на запрос OPTIONS с этими заголовками.

Это запрос из разных источников, и он подлежит так называемой предварительной проверке. Перед выполнением запроса PUT или DELETE браузер спрашивает целевой веб-сервер, безопасно ли это делать с веб-страницы в другом домене. Он запрашивает это с помощью метода OPTIONS. Если целевой сервер не разрешит, веб-браузер никогда не сделает запрос PUT или DELETE. Он должен выполнить предварительную проверку запроса, потому что после того, как он сделал PUT или DELETE, уже слишком поздно выполнять ответ; возможна утечка конфиденциальной информации.

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

спецификация CORS содержит кровавые подробности. Суть в том, что коду на вашей веб-странице не будет разрешено делать эти запросы, если целевой веб-сервер не поддерживает метод OPTIONS, а ответ на метод OPTIONS включает заголовки, говорящие о том, что такие запросы разрешены.

person Charles Engelke    schedule 21.01.2013
comment
Хорошо, это имеет смысл. Никогда сознательно не сталкиваясь с предварительной проверкой, может быть, у вас есть простой пример того, как правильно обрабатывать/реализовывать первый вызов OPTION и, предположительно, следующий вызов PUT? - person GDP; 21.01.2013
comment
Я думаю, я не понимаю, как настроить целевой веб-сервер, чтобы разрешить ОПЦИИ (я только что добавил это в разрешенные параметры, но с тем же результатом), а затем распознать/обработать ответ, в котором говорится, что такие запросы разрешены. - person GDP; 21.01.2013
comment
Извините, я ничего не знаю о фреймворке Luracast Restler API. Он работает под Apache? - person Charles Engelke; 21.01.2013
comment
Да, это так. Это прекрасно работает, я просто не могу правильно настроить Apache. Подробности на странице restler3.luracast.com/examples/_007_crud/readme.html. - person GDP; 21.01.2013
comment
Извините, я думаю, вам придется выяснить, как заставить его работать в этой конкретной среде. - person Charles Engelke; 22.01.2013