AJAX in Chrom Versand-OPTIONEN anstelle von GET/POST/PUT/DELETE?

Ich arbeite auf einer internen web-Applikation bei der Arbeit. Im IE10 die Anfragen funktionieren, aber in Chrome alle AJAX-Anfragen (davon gibt es viele) werden per OPTIONEN anstelle von was auch immer definierten Methode, die ich gebe. Technisch meine Anforderungen sind: "cross-domain." Die Website wird serviert auf localhost:6120 und den service, den ich bin die Bereitstellung von AJAX-Anfragen zu ist auf 57124. Diese geschlossene jquery bug definiert das Problem aber nicht wirklich beheben.

Was kann ich tun, um über die korrekte http-Methode in ajax-Anfragen?

Edit:

Dies ist in dem Dokument laden jeder Seite:

jQuery.support.cors = true;

Und jeder AJAX ist ähnlich aufgebaut:

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

Der Letzte Kommentar in diesem bug-report erklärt, es ziemlich gut...
Es umgedreht, mein Geist, weil alles, was ich Tue, ist so Vanille (und mein code ist ähnlich wie in den jquery-Fehler). Das beiseite, es ist keine Ausrede, nicht darunter. BRB, greifen einige Beispiel-code.
Beachten Sie, dass IE nicht der Auffassung, port-Nummern bei der Bestimmung, ob eine Anforderung ist cross-origin.
Unsere REST-Dienst nutzt unterschiedliche Anforderungen, wie verschiedene Dinge zu tun basierend auf der http-Methode. Schalten alles, um nicht einen gültigen fix. Auch nach Dark Falcon ' s Antwort, es wird nicht helfen, da ich eh noch X-Benutzernamen und andere benutzerdefinierte Header bei Anfragen.
das ändert nicht die Tatsache, dass, wenn Sie wollen, um einen cross-origin-Anfrage, müssen Sie alle Regeln, die anwendbar sind, um cross-origin-requests, um richtig zu funktionieren. cross-origin-requests in der Regel um eine OPTIONS-Anfrage. Behandeln Sie es richtig und das problem wird Weggehen. Die einzige andere Möglichkeit, dies zu lösen (ohne änderung der api) ist, um ein Skript auf dem gleichen server wie die primäre Seite für die Interaktion mit der api-Verwendung von server-side code.

InformationsquelleAutor Corey Ogburn | 2014-02-14

124

Chrome ist für die Preflight-Prüfung der Anfrage zu suchen CORS Header. Wenn der Antrag zulässig ist, dann senden Sie das eigentliche Anliegen. Wenn Sie dies tun, cross-domain, werden Sie einfach mit ihm zu beschäftigen, oder sonst einen Weg finden, um eine Anfrage zu nicht-cross-domain. Dies ist der Grund, warum die jQuery-bug wurde geschlossen, als nicht-fix. Das ist by design.
Im Gegensatz zu einfachen Anfragen (wie oben erläutert), "Preflight" - Anforderungen erste
senden einer HTTP-Anforderung, indem Sie die OPTIONEN-Methode auf die Ressource auf dem
andere domain, um festzustellen, ob die tatsächliche Anforderung ist sicher
zu senden. Cross-site-requests sind preflighted wie diese, da Sie
Auswirkungen auf user-Daten. Insbesondere eine Anforderung ist
Preflight wenn:
- Es verwendet andere Methoden als GET, HEAD oder POST. Auch, wenn die POST wird verwendet, um Anfrage senden Daten mit einem Content-Typ als
  application/x-www-form-urlencoded, multipart/form-data oder text/plain,
  wenn z.B. die POST-Anforderung sendet eine XML-Nutzlast an den server mit
  application/xml oder text/xml ist, dann ist die Anforderung preflighted.
- Es legt benutzerdefinierte Header in der Anforderung (z.B. die Abfrage verwendet einen header wie X-PINGOTHER)
Benutzerdefinierte Header. Das ist wahrscheinlich das, was die Einstellungen aus dem preflight-OPTIONEN aufruft.

InformationsquelleAutor Dark Falcon
15

Basiert auf der Tatsache, dass die Anfrage nicht gesendet, der auf dem Standard-port 80/443 dieser Ajax-Aufruf automatisch als cross-origin resource (CORS) Anfrage, was in anderen Worten bedeutet, dass die Anforderung automatisch eine OPTIONS-Anfrage, die prüft, für CORS-Header auf dem server/servlet-Seite.

Dies geschieht selbst dann, wenn Sie
```
crossOrigin: false;
```
oder auch wenn Sie ommit.

Der Grund ist einfach, dass localhost != localhost:57124. Versuchen Sie, senden Sie es nur auf localhost ohne den Hafen - es wird fehlschlagen, da das angeforderte Ziel nicht erreichbar sein, jedoch feststellen, dass, wenn der domain-Namen sind gleich, die Anfrage gesendet wird, ohne die OPTIONS-Anforderung, bevor Sie POSTEN.

InformationsquelleAutor Dropout
3

Ich Stimme mit Kevin B, der bug-report sagt alles. Es klingt wie Sie versuchen, um cross-domain-ajax-Aufrufe. Wenn Sie nicht vertraut mit der same-origin-policy können Sie hier starten: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript.

Wenn dies nicht beabsichtigt ist, eine cross-domain-ajax-call, versuchen Sie, Ihre Ziel-url für relative und sehen, ob das problem verschwindet. Wenn Sie wirklich verzweifelt schauen Sie in die JSONP, aber Vorsicht, Chaos lauert. Es gibt wirklich nicht viel mehr wir tun können, um Ihnen zu helfen.

Unser system Struktur ist etwas, was ich nicht ändern kann. Einen anderen port verwenden ist ein Erfordernis unserer Architektur. Ich bekomme same-origin-policy, dachte aber, dass die CORS wir umgesetzt wurde genug. Anscheinend nicht.
Wenn Ihr server liefert JSON-Antworten, können Sie sich in JSONP-Methode, nur verwenden Sie es verantwortungsbewusst.
Ich weiß nicht wirklich, mit Ihnen zu streiten, aber JSONP verwendet die script-tags zu ziehen, die Daten aus einer anderen Domäne und sendet dann das Ergebnis an eine callback-Funktion. Es ist viel schwerer, wenn das Ergebnis nicht json.
Nein, es ist nicht viel schwieriger. In der Tat die Antwort sollte nicht sein gültiges JSON-in jedem Fall. Stattdessen sollte der server zurückzukehren, so etwas wie dieses: callbackfunc(somedata). Wie Sie sehen können, dies ist kein gültiges JSON. Und, somedata kann ein string oder eine Zahl, oder was auch immer Sie möchten, es zu sein.
Ich bin mit Briefträger und gibt den request-Methoden korrekt gesendet werden (zB. "SETZEN", "LÖSCHEN", etc). Aber wenn ich versuche es aus meinem code immer senden Sie Sie mit der request-Methode OPTIONEN. Ich habe keine Ahnung, wie der Postbote ist in der Lage, es zu tun.

InformationsquelleAutor jgitter
1

Wenn es möglich ist, übergeben Sie die Parameter durch regelmäßige GET/POST mit einem anderen Namen und lassen Sie Ihre server-side-code verarbeitet.

Ich hatte ein ähnliches Problem mit meinen eigenen proxy zu umgehen CORS und ich habe den gleichen Fehler von POST->OPTION in Chrome. Es war die Authorization header in meinem Fall ("x-li-format" und "X-UserName" hier in deinem Fall.) Ich landete Weitergabe es in einem dummy-format (z.B. AuthorizatinJack im KOMMEN), und ich änderte den code für meinen proxy zu drehen, die in einen header, wenn der Anruf zum Ziel. Hier ist es in PHP:
```
if (isset($_GET['AuthorizationJack'])) {
    $request_headers[] = "Authorization: Basic ".$_GET['AuthorizationJack'];
}
```
InformationsquelleAutor Aidin
1

In meinem Fall bin ich dem Aufruf einer API-hosted by AWS-API (Gateway). Der Fehler ist passiert, als ich versuchte, rufen Sie die API aus einer anderen Domäne als der API eine eigene domain. Da bin ich der API-Besitzer habe ich aktiviert CORS für die Testumgebung beschrieben, in der Amazon Dokumentation.

In der Produktion dieser Fehler wird nicht passieren, da die Anfrage und die api wird in der gleichen Domäne sein.

Ich hoffe, es hilft!

InformationsquelleAutor gbonesso

Als beantwortet von @Dark Falcon, ich einfach behandelt es.

In meinem Fall, ich bin mit node.js server, und erstellen Sie eine Sitzung, wenn es nicht vorhanden ist. Da die OPTIONS-Methode nicht die session-details, dann ist es am Ende die Schaffung einer neuen Sitzung für jede POST-Methode auf Anfrage.

Also in meinem app-routine zu erstellen-Sitzung-wenn-nicht-vorhanden ist, habe ich nur noch eine Prüfung um zu sehen, ob die Methode ist OPTIONS, und wenn dem so ist, einfach überspringen Sitzung erstellen Teil:

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

InformationsquelleAutor Mahesh

0

"Preflight" - Anfragen zuerst senden einer HTTP-Anforderung, indem Sie die OPTIONEN-Methode, um die Ressource auf der anderen domain, um festzustellen, ob die tatsächliche Anforderung ist sicher zu senden. Cross-site-requests

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Könntest du ein bisschen mehr Informationen? Deine Antwort sieht aus wie ein Kommentar. 🙂

InformationsquelleAutor Noorullah

Erwägen Sie die Verwendung axios

axios.get( url,
{ headers: {"Content-Type": "application/json"} } ).then( res => {

  if(res.data.error) {

  } else { 
    doAnything( res.data )
  }

}).catch(function (error) {
   doAnythingError(error)
});

Hatte ich dieses Problem mit Holen und axios funktionierte perfekt.

Axios auch verwenden, ersten OPTIONEN

InformationsquelleAutor Evhz

0

Ich angetroffen habe ein sehr ähnliches Problem. Ich verbrachte fast den halben Tag, um zu verstehen, warum alles funktioniert einwandfrei in Firefox und scheitert in Chrome. In meinem Fall war es wegen der doppelten (oder vielleicht falsch) Felder in meinem request-header.

InformationsquelleAutor Andrew Tatomyr

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.