jQuery $ .ajax (), $ .post che invia "OPTIONS" come REQUEST_METHOD in Firefox

Problemi con quello che pensavo fosse un plugin jQuery relativamente semplice ...

Il plugin dovrebbe recuperare i dati da uno script php tramite Ajax per aggiungere opzioni a <select>. La richiesta Ajax è piuttosto generica:

$.ajax({
  url: o.url,
  type: 'post',
  contentType: "application/x-www-form-urlencoded",
  data: '{"method":"getStates", "program":"EXPLORE"}',
  success: function (data, status) {
    console.log("Success!!");
    console.log(data);
    console.log(status);
  },
  error: function (xhr, desc, err) {
    console.log(xhr);
    console.log("Desc: " + desc + "\nErr:" + err);
  }
});

Questo sembra funzionare bene in Safari. In Firefox 3.5, REQUEST_TYPEsul server è sempre 'OPTIONS' e i dati $ _POST non vengono visualizzati. Apache registra la richiesta come tipo "OPZIONI":

::1 - - [08/Jul/2009:11:43:27 -0500] "OPTIONS sitecodes.php HTTP/1.1" 200 46

Perché questa chiamata Ajax dovrebbe funzionare in Safari, ma non in Firefox, e come posso ripararla per Firefox?

Header di risposta
Data: mer 08 lug 2009 21:22:17 GMT
Server: Apache / 2.0.59 (Unix) PHP / 5.2.6 DAV / 2
X-Powered-By: PHP / 5.2.6
Lunghezza contenuto 46
Timeout keep-alive = 15, max = 100
Connessione Keep-Alive
Tipo di contenuto text / html

Richiedi intestazioni
Modulo d'ordine dell'host: 8888
User-Agent Mozilla / 5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: 1.9.1) Gecko / 20090624 Firefox / 3.5
Accetta testo / html, application / xhtml + xml, application / xml; q = 0.9, * / *; q = 0.8
Accept-Language en-us, en; q = 0,5
Accetta-codifica gzip, deflate
Accept-Charset ISO-8859-1, utf-8; q = 0.7, *; q = 0.7
Keep-Alive 300
Connessione keep-alive
Origine http://ux.inetu.act.org
POST Metodo di controllo accessi
Access-Control-Request-Headers x-richiesto-con

Ecco un'immagine dell'output di Firebug:

Il motivo dell'errore è la stessa politica di origine. Ti consente solo di fare richieste XMLHTTP al tuo dominio. Vedi invece se puoi usare un callback JSONP :

$.getJSON( 'http://<url>/api.php?callback=?', function ( data ) { alert ( data ); } );

Ho usato il seguente codice sul lato Django per interpretare la richiesta OPTIONS e impostare le intestazioni Access-Control richieste. Dopo questo le mie richieste interdominio da Firefox hanno iniziato a funzionare. Come detto prima, il browser invia prima la richiesta OPTIONS e poi immediatamente dopo il 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":
        # ... 

Modifica: sembra che almeno in alcuni casi sia necessario aggiungere le stesse intestazioni Access-Control alla risposta effettiva. Questo può essere un po 'confuso, poiché la richiesta sembra avere successo, ma Firefox non passa il contenuto della risposta a Javascript.

Questo articolo del centro per sviluppatori di Mozilla descrive vari scenari di richiesta tra domini. L'articolo sembra indicare che una richiesta POST con tipo di contenuto di "application / x-www-form-urlencoded" dovrebbe essere inviata come "semplice richiesta" (senza richiesta "preflight" OPTIONS). Ho scoperto, tuttavia, che Firefox ha inviato la richiesta OPTIONS, anche se il mio POST è stato inviato con quel tipo di contenuto.

Sono stato in grado di farlo funzionare creando un gestore di richieste di opzioni sul server, che ha impostato l'intestazione di risposta 'Access-Control-Allow-Origin' su '*'. Puoi essere più restrittivo impostandolo su qualcosa di specifico, come " http://someurl.com ". Inoltre, ho letto che, presumibilmente, puoi specificare un elenco separato da virgole di più origini, ma non sono riuscito a farlo funzionare.

Quando Firefox riceve la risposta alla richiesta OPTIONS con un valore 'Access-Control-Allow-Origin' accettabile, invia la richiesta POST.

Ho risolto questo problema usando una soluzione interamente basata su Apache. Nel mio vhost / htaccess ho inserito il seguente blocco:

# 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]

Potrebbe non essere necessaria l'ultima parte, a seconda di cosa succede quando Apache esegue lo script di destinazione. Il merito va all'amichevole ServerFault per l'ultima parte.

Questo PHP nella parte superiore dello script di risposta sembra funzionare. (Con Firefox 3.6.11. Non ho ancora fatto molti test.)

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);
}

Ho avuto lo stesso problema con l'invio di richieste a Google Maps e la soluzione è abbastanza semplice con jQuery 1.5 - per l'utilizzo di dataType dataType: "jsonp"

Culprit è una richiesta di verifica preliminare che utilizza il metodo OPTIONS

Per i metodi di richiesta HTTP che possono causare effetti collaterali sui dati utente (in particolare, per metodi HTTP diversi da GET o per l'utilizzo POST con determinati tipi MIME), la specifica impone che i browser "eseguano il preflight" della richiesta, sollecitando i metodi supportati dal server con un metodo di richiesta OPTIONS HTTP, quindi, dopo "approvazione" dal server, inviando la richiesta effettiva con il metodo di richiesta HTTP effettivo.

Le specifiche Web si riferiscono a: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Ho risolto il problema aggiungendo le seguenti righe in 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;
                }
    }

Stavo guardando attraverso la fonte 1.3.2, quando usavo JSONP, la richiesta viene fatta costruendo un elemento SCRIPT in modo dinamico, che supera i criteri dello stesso dominio del browser. Naturalmente, non è possibile effettuare una richiesta POST utilizzando un elemento SCRIPT, il browser recupera il risultato utilizzando GET.

Quando si richiede una chiamata JSONP, l'elemento SCRIPT non viene generato, poiché lo fa solo quando il Tipo di chiamata AJAX è impostato su GET.

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

Abbiamo avuto un problema come questo con ASP.Net. Il nostro IIS stava restituendo un errore interno del server durante il tentativo di eseguire un jQuery $.postper ottenere alcuni contenuti html a causa di PageHandlerFactory era limitato a rispondere soloGET,HEAD,POST,DEBUG verbi. Quindi puoi modificare tale restrizione aggiungendo il verbo "OPZIONI" all'elenco o selezionando "Tutti i verbi"

Puoi modificarlo in Gestione IIS, selezionando il tuo sito Web, quindi selezionando Mapping gestori, fai doppio clic nel tuo PageHandlerFactory per i file * .apx di cui hai bisogno (Usiamo il pool di applicazioni integrate con Framework 4.0). Fai clic su Richiedi restrizioni, quindi vai a Verbi Tabn e applica la modifica.

Ora la nostra $.postrichiesta funziona come previsto :)

Verifica se l' actionURL del modulo include la wwwparte del dominio, mentre la pagina originale che hai aperto viene visualizzata senza www.

Tipicamente fatto per URL canonici.

Ho lottato per ore prima di imbattermi in questo articolo e ho trovato il suggerimento di Cross Domain.

Sembra che se o.url = 'index.php'e questo file esista sia ok e restituisca un messaggio di successo nella console. Restituisce un errore se uso url:http://www.google.com

Se stai facendo una richiesta di posta, perché non usare direttamente il metodo $ .post :

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

È molto più semplice.

Ho pubblicato un chiaro esempio di come risolverlo se controlli il codice del server del dominio a cui stai POSTANDO. Questa risposta è toccata in questa discussione, ma questo spiega più chiaramente l'IMO.

Come posso inviare una richiesta POST tra domini tramite JavaScript?

La soluzione a questo è:

1. usa dataType: json
2. aggiungi &callback=?al tuo URL

questo ha funzionato chiamando l'API di Facebook e con Firefox. Firebug utilizza GETinvece che OPTIONScon le condizioni sopra (entrambe).

Un'altra possibilità per aggirare il problema è utilizzare uno script proxy. Tale metodo è descritto ad esempio qui

Puoi provare questo senza

contentType:application/x-www-form-urlencoded

Prova ad aggiungere l'opzione:

dataType: "json"

 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);

     }
});         
}

Ho avuto un problema simile con il tentativo di utilizzare l'API di Facebook.

L'unico contentType che non ha inviato la richiesta di preflight sembrava essere solo text / plain ... non il resto dei parametri menzionati su mozilla qui

• Perché questo è l'unico browser che lo fa?
• Perché Facebook non conosce e accetta la richiesta di verifica preliminare?

Cordiali saluti: Il suddetto documento Moz suggerisce che le intestazioni di X-Lori dovrebbero innescare una richiesta preflight ... non lo fa.

Devi fare un po 'di lavoro sul lato server. Vedo che stai utilizzando PHP sul lato server, ma la soluzione per l'applicazione Web .NET è qui: Impossibile impostare il tipo di contenuto su "application / json" in jQuery.ajax

Fai lo stesso con lo script PHP e funzionerà. Semplicemente: a prima richiesta il browser chiede al server se è consentito inviare tali dati con tale tipo e la seconda richiesta è corretta / consentita.

Prova ad aggiungere quanto segue:

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

Ho usato un URL proxy per risolvere un problema simile quando desidero pubblicare dati sul mio apache solr ospitato su un altro server. (Questa potrebbe non essere la risposta perfetta ma risolve il mio problema.)

Segui questo URL: Usando Mode-Rewrite per il proxy , aggiungo questa riga al mio httpd.conf:

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

Pertanto, posso semplicemente pubblicare dati su / solr invece di pubblicare dati su http: // ip: 8983 / solr / *. Quindi pubblicherà i dati nella stessa origine.

Ho già questo codice che gestisce bene la mia situazione cors in php:

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

E funzionava bene localmente e in remoto, ma non per i caricamenti in remoto.

Qualcosa accade con apache / php O il mio codice, non mi sono preoccupato di cercarlo, quando richiedi OPZIONI restituisce la mia intestazione con le regole cors ma con 302 risultati. Pertanto il mio browser non riconosce una situazione accettabile.

Quello che ho fatto, basato sulla risposta di @Mark McDonald, è stato semplicemente inserire questo codice dopo la mia intestazione:

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

Ora, quando richiesto OPTIONS, invierà solo l'intestazione e il risultato 202.

Si prega di essere avvisato:

JSONP supporta solo il metodo di richiesta GET.

* Invia richiesta da firefox : *

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

Sopra la richiesta invia tramite OPTIONS (while ==> type: 'POST' ) !!!!

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

Ma sopra la richiesta invia da GET (mentre ==> digita: 'POST' ) !!!!

Quando sei in "comunicazione tra domini", presta attenzione e stai attento.