Междудомейн AJAX повикване към API на Luracast Restler: ОПЦИИ за изпращане PUT и DELETE - Защо?

Инсталирах рамката на Restler API на Luracast и имам невероятен успех с всичко това, освен когато изпращам 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 на локален хост и на кръстосан домейн


person GDP    schedule 21.01.2013    source източник
comment
Това може да помогне: stackoverflow.com/q/5750696/535275   -  person Scott Hunter    schedule 21.01.2013


Отговори (1)


Имате правилните заглавки на отговор, но трябва да накарате вашия сървър да отговори на заявка 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