AJAX en Chrome OPTIONS d'envoi au lieu de GET/POST/PUT/DELETE?

Je travaille sur une application web interne au travail. Dans IE10 la demande de travail est bien, mais en Chrome toutes les requêtes AJAX (qui sont nombreux) sont envoyés à l'aide des OPTIONS de la place de ce que définis méthode je la donne. Techniquement, mes demandes sont "cross domain." Le site est servi sur localhost:6120 et le service, je suis en train de faire des requêtes AJAX est sur 57124. Ce fermé jquery bug définit le problème, mais pas une vraie solution.

Que puis-je faire pour utiliser la bonne méthode http à des requêtes ajax?

Edit:

C'est dans le document de charge de chaque page:

jQuery.support.cors = true;

Et chaque AJAX est construit de la même façon:

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"
});
  • Le dernier commentaire dans ce rapport de bug, il explique assez bien...
  • Il renversé mon esprit parce que tout ce que je fais est donc à la vanille (et mon code est similaire à celle dans le jquery bug). Cela mis à part, il n'y a aucune excuse pour ne pas l'inclure. BRB, l'accaparement des exemples de code.
  • Notez que IE ne considère pas les numéros de port au moment de déterminer si une demande est cross-origin.
  • Notre service REST tire parti des différentes demandes que font les différents éléments en fonction de la méthode http. La commutation tout pour l'OBTENIR n'est pas valide d'un correctif. Aussi, selon Sombre Falcon réponse, il ne vous aidera pas de toute façon parce que j'ai X-nom d'utilisateur et d'autres en-têtes personnalisés à la demande.
  • cela ne change pas le fait que si vous voulez faire une croix-origine de la demande, vous devez suivre toutes les règles qui sont applicables à la croix-de l'origine des demandes pour qu'il fonctionne correctement. la croix-origine des demandes impliquent généralement une demande OPTIONS. Le gérer correctement et que le problème va disparaître. La seule autre façon de résoudre ce problème (sans modification de l'api) est d'avoir un script sur le même serveur que la page principale qui interagit avec l'api à l'aide de code côté serveur.
InformationsquelleAutor Corey Ogburn | 2014-02-14
  1. 125

    Chrome est le contrôle en amont de la demande de chercher De la SCRO en-têtes. Si la demande est acceptable, il sera alors d'envoyer la requête réelle. Si vous êtes en train de faire ce cross-domain, vous aurez simplement à traiter avec elle, ou bien trouver un moyen de faire la demande de non-inter-domaine. C'est pourquoi le jQuery bug a été fermé parce que ne veut pas le réparer. C'est par la conception.

    Contrairement à une simple demande (voir ci-dessus), "contrôlé" les demandes de première
    envoyer une requête HTTP par la méthode des OPTIONS de la ressource sur le
    dans un autre domaine, afin de déterminer si la demande est sûr
    pour envoyer. Les requêtes inter-domaines sont contrôlé comme cela, car ils peuvent
    avoir des implications pour les données de l'utilisateur. En particulier, une demande est
    contrôlé si:

    • Il utilise des méthodes autres que GET, HEAD ou par la POSTE. Aussi, si le POST est utilisée pour envoyer les données de la demande avec un Type de Contenu autres que
      application/x-www-form-urlencoded, multipart/form-data, ou text/plain,
      par exemple, si la requête POST envoie une charge utile XML au serveur à l'aide
      application/xml ou texte/xml, alors que la demande est contrôlé.
    • Il définit les en-têtes personnalisés à la demande (par exemple, la demande utilise un en-tête tel que X-PINGOTHER)
    • En-têtes personnalisés. C'est probablement ce qui est de la définition de la OPTIONS de contrôle en amont des appels.
    InformationsquelleAutor Dark Falcon
  2. 15

    Basée sur le fait que la demande n'est pas envoyé sur le défaut de port 80/443 cet appel Ajax est automatiquement considéré comme un cross-origin resource (SCRO) demande, qui en d'autres termes signifie que la demande émet automatiquement une demande d'OPTIONS qui vérifie la SCRO en-têtes sur le serveur de l'/servlet côté.

    Ce qui se passe, même si vous réglez

    crossOrigin: false;

    ou même si vous omettre cela.

    La raison en est simplement que localhost != localhost:57124. Essayez de l'envoyer seulement à localhost sans le port - elle sera un échec, car la demande de la cible ne sera pas accessible, convient toutefois de remarquer que si les noms de domaine sont égaux la demande est envoyée sans les OPTIONS de demande avant de POSTER.

    InformationsquelleAutor Dropout
  3. 3

    Je suis d'accord avec Kevin B, le rapport de bug, tout est dit. Il semble que vous essayez de faire de la croix-domaine des appels ajax. Si vous n'êtes pas familier avec la même origine, vous pouvez commencer ici: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Same_origin_policy_for_JavaScript.

    Si ce n'est pas destiné à être un cross-domain appel ajax, essayez de faire votre url de la cible relative et voir si le problème disparaît. Si vous êtes vraiment désespéré regarder dans le JSONP, mais méfiez-vous, le chaos se cache. Il n'y a vraiment pas beaucoup plus que nous pouvons faire pour vous aider.

    • Notre système de structure est quelque chose que je ne peux pas changer. En utilisant un autre port est une exigence de notre architecture. Je reçois même origine, mais la pensée que de la SCRO nous avons mis en place a été assez. Apparemment pas.
    • Si votre serveur renvoie des réponses JSON, vous pouvez regarder dans JSONP méthode, il suffit d'utiliser de manière responsable.
    • JSON n'a rien à voir avec JSONP
    • Je n'ai pas vraiment soin de discuter avec vous, mais JSONP utilise des balises de script pour extraire des données à partir d'un autre domaine, puis envoie le résultat d'une fonction de rappel. Il est beaucoup plus difficile si le résultat n'est pas du json.
    • Non, il n'est pas beaucoup plus difficile. En fait, la réponse ne doit pas être JSON valide dans tous les cas. Au lieu de cela, le serveur doit renvoyer quelque chose comme ceci: callbackfunc(somedata). Comme vous pouvez le voir, ce n'est pas JSON valide. Et, somedata peut être une chaîne de caractères ou un nombre, ou ce que vous voulez qu'il soit.
    • Juste assez. Mais sérieusement, ne pas se disputer.
    • JSONP est certainement quelque chose à faire avec JSON. Bien que mal nommée, il est "JSON avec un rembourrage" où le rappel est le remplissage. Alors que vous pouvez l'utiliser pour d'autres fins que JSON, le point et l'intention d'utilisation de JSONP est d'obtenir de la croix-origine JSON de travail. en.wikipedia.org/wiki/JSONP "de manière conventionnelle, il est un code JavaScript fragment qui invoque un appel de fonction de certaines données au format JSON."
    • JSONP a autant à voir avec JSON comme il le fait avec HTML ou XML, ou <insérer des données en format ici>. Comme vous l'avez dit, JSONP peut fonctionner sur toutes les données. C'était vraiment mon point de vue, et que le serveur n'a pas de retour JSON, au lieu de cela, elle renvoie une invocation de la fonction.
    • Je suis en utilisant le Facteur, et là, les méthodes de demande sont envoyés correctement (par exemple. 'PUT', 'DELETE', etc). Mais quand j'essaie de le faire à partir de mon code il toujours les envoyer avec la demande de la méthode des OPTIONS. Je n'ai aucune idée de comment le Facteur est en mesure de le faire.
    • je rencontre aussi le même scénario @ErwinGO. Probablement dépend du facteur de définir ses appels

    InformationsquelleAutor jgitter
  4. 1

    Si il est possible de passer les paramètres à travers ordinaire GET/POST avec un nom différent et laissez votre côté serveur code gère.

    J'ai eu un problème similaire avec mon propre proxy pour contourner la SCRO et j'ai eu la même erreur de POST->OPTION Chrome. C'était la Authorization d'en-tête dans mon cas ("x-li-format" et "X-UserName" ici dans votre cas.) J'ai fini par passer sous un mannequin format (par exemple, AuthorizatinJack à OBTENIR) et j'ai modifié le code pour ma procuration pour le transformer en un en-tête lors de la prise de l'appel à la destination. Ici, il est en PHP:

    if (isset($_GET['AuthorizationJack'])) {
    $request_headers[] = "Authorization: Basic ".$_GET['AuthorizationJack'];
}
    InformationsquelleAutor Aidin
  5. 1

    Dans mon cas, je suis d'appeler une API hébergé par AWS (Passerelle API). L'erreur qui s'est passé quand j'ai essayé d'appeler l'API à partir d'un autre domaine que l'API propre nom de domaine. Depuis que je suis l'API propriétaire, j'ai activé la SCRO pour l'environnement de test, comme décrit dans la Amazon Documentation.

    Dans la production de cette erreur ne se produira pas, car la demande et de l'api sera dans le même domaine.

    J'espère que cela aide!

    InformationsquelleAutor gbonesso
  6. 0

    Comme répondu par @Dark Falcon, je simplement traité avec elle.

    Dans mon cas, je suis en utilisant node.js serveur, et la création d'une session si elle n'existe pas. Étant donné que les OPTIONS de la méthode n'a pas la session de détails en elle, elle a fini par créer une nouvelle session pour chaque POSTE de la demande de méthode.

    Donc, dans mon application de routine pour créer de session-si-pas-exister, j'ai juste ajouté une vérification pour voir si la méthode est OPTIONS, et si oui, il suffit de sauter session de création de partie:

        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
  7. 0

    "contrôlé" demande d'abord envoyer une requête HTTP par la méthode des OPTIONS à la ressource sur l'autre domaine, afin de déterminer si la demande est sûr d'envoyer. Les requêtes inter-domaines

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

    • Pourriez-vous ajouter un peu plus d'informations? Votre réponse ressemble à un commentaire. 🙂
    InformationsquelleAutor Noorullah
  8. 0

    Envisager d'utiliser axios

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

  if(res.data.error) {

  } else { 
    doAnything( res.data )
  }

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

    J'ai eu ce problème à l'aide de fetch et axios a parfaitement fonctionné.

    • Axios utilisons aussi des OPTIONS
    InformationsquelleAutor Evhz
  9. 0

    J'ai rencontré un très semblable question. J'ai passé presque une demi-journée pour comprendre pourquoi tout fonctionne correctement dans Firefox et échoue dans Chrome. Dans mon cas, c'était à cause de la double (ou peut-être une erreur de frappe) les champs dans mon en-tête de requête.

    InformationsquelleAutor Andrew Tatomyr