Impossible de définir content-type à ‘application / json’ dans jQuery.ajax

Quand j’ai ce code

$.ajax({ type: 'POST', //contentType: "application/json", url: 'http://localhost:16329/Hello', data: { name: 'norm' }, dataType: 'json' }); 

dans Fiddler, je peux voir la demande brute suivante

 POST http://localhost:16329/Hello HTTP/1.1 Host: localhost:16329 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Accept: application/json, text/javascript, */*; q=0.01 Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Content-Type: application/x-www-form-urlencoded; charset=UTF-8 Referer: http://localhost:14693/WebSite1/index.html Content-Length: 9 Origin: http://localhost:14693 Pragma: no-cache Cache-Control: no-cache name=norm 

Mais j’essaie de définir content-type de l’ application / x-www-form-urlencoded à application / json . Mais ce code

 $.ajax({ type: "POST", contentType: "application/json", url: 'http://localhost:16329/Hello', data: { name: 'norm' }, dataType: "json" }); 

Génère une requête étrange (que je peux voir dans Fiddler)

 OPTIONS http://localhost:16329/Hello HTTP/1.1 Host: localhost:16329 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive Origin: http://localhost:14693 Access-Control-Request-Method: POST Access-Control-Request-Headers: content-type Pragma: no-cache Cache-Control: no-cache 

Pourquoi donc? Qu’est-ce qu’OPTIONS quand il devrait y être POST? Et où mon type de contenu est-il défini sur application / json? Et les parameters de demande ont disparu pour une raison quelconque.

MISE À JOUR 1

Côté serveur, j’ai un service RESTful très simple.

 [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)] public class RestfulService : IRestfulService { [WebInvoke( Method = "POST", UriTemplate = "Hello", ResponseFormat = WebMessageFormat.Json)] public ssortingng HelloWorld(ssortingng name) { return "hello, " + name; } } 

Mais pour une raison quelconque, je ne peux pas appeler cette méthode avec des parameters.

MISE À JOUR 2

Désolé de ne pas avoir répondu aussi longtemps.

J’ai ajouté ces en-têtes à la réponse de mon serveur

  Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Methods: POST, GET, OPTIONS 

Cela n’a pas aidé, j’ai la méthode non autorisée erreur du serveur.

Voici ce que dit mon violoneux

entrer la description de l'image ici

Donc, maintenant je peux être sûr que mon serveur accepte les POST, GET, OPTIONS (si les en-têtes de réponse fonctionnent comme prévu). Mais pourquoi “Méthode non autorisée”?

Dans la réponse WebView du serveur (vous pouvez voir la réponse brute sur l’image ci-dessus) ressemble à ceci

entrer la description de l'image ici

    Il semblerait que la suppression de http:// partir de l’option url garantit l’envoi de l’en-tête HTTP POST correct.

    Je ne pense pas que vous ayez besoin de qualifier complètement le nom de l’hôte, utilisez simplement une URL relative comme ci-dessous.

      $.ajax({ type: "POST", contentType: "application/json", url: '/Hello', data: { name: 'norm' }, dataType: "json" }); 

    Un exemple du mien qui fonctionne:

      $.ajax({ type: "POST", url: siteRoot + "api/SpaceGame/AddPlayer", async: false, data: JSON.ssortingngify({ Name: playersShip.name, Credits: playersShip.credits }), contentType: "application/json", complete: function (data) { console.log(data); wait = false; } }); 

    Peut-être lié: jQuery $ .ajax (), $ .post envoyant “OPTIONS” en tant que REQUEST_METHOD dans Firefox

    Edit: Après quelques recherches, j’ai découvert que l’en-tête OPTIONS est utilisé pour déterminer si la requête du domaine d’origine est autorisée. Avec fiddler, j’ai ajouté les éléments suivants aux en-têtes de réponse de mon serveur.

      Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Content-Type Access-Control-Allow-Methods: POST, GET, OPTIONS 

    Une fois que le navigateur a reçu cette réponse, il a alors envoyé la demande POST correcte avec les données json. Il semblerait que le type de contenu par défaut format-url-encodé est considéré comme sûr et ne subit donc pas les vérifications supplémentaires entre domaines.

    Il semblerait que vous deviez append les en-têtes mentionnés précédemment à la réponse de vos serveurs à la requête OPTIONS. Bien entendu, vous devez les configurer pour autoriser les requêtes provenant de domaines spécifiques plutôt que tous.

    J’ai utilisé le jQuery suivant pour le tester.

     $.ajax({ type: "POST", url: "http://myDomain.com/path/AddPlayer", data: JSON.ssortingngify({ Name: "Test", Credits: 0 }), //contentType: "application/json", dataType: 'json', complete: function(data) { $("content").html(data); } });​ 

    Les références:

    Je peux vous montrer comment je l’ai utilisé

      function GetDenierValue() { var denierid = $("#productDenierid").val() == '' ? 0 : $("#productDenierid").val(); var param = { 'productDenierid': denierid }; $.ajax({ url: "/Admin/ProductComposition/GetDenierValue", dataType: "json", contentType: "application/json;charset=utf-8", type: "POST", data: JSON.ssortingngify(param), success: function (msg) { if (msg != null) { return msg.URL; } } }); } 

    Donc, tout ce que vous devez faire pour que cela fonctionne est d’append:

     headers: { 'Accept': 'application/json', 'Content-Type': 'application/json' } 

    en tant que champ à votre demande de publication et cela fonctionnera.

    J’ai reconnu ces écrans, j’utilise CodeFluentEntities et j’ai aussi une solution qui a fonctionné pour moi.

    J’utilise cette construction:

     $.ajax({ url: path, type: "POST", contentType: "text/plain", data: {"some":"some"} } 

    comme vous pouvez le voir, si j’utilise

     contentType: "", 

    ou

     contentType: "text/plain", //chrome 

    Tout fonctionne bien.

    Je ne suis pas sûr à 100% que c’est tout ce dont vous avez besoin, car j’ai aussi changé les en-têtes.

    J’ai trouvé la solution à ce problème ici . N’oubliez pas d’autoriser le verbe OPTIONS sur le gestionnaire de service de l’application IIS.

    Fonctionne bien Merci André Pedroso. 🙂

    J’ai eu le même problème. Je lance une application de repos Java sur un serveur jboss. Mais je pense que la solution est similaire sur une application Web ASP .NET.

    Firefox effectue un pré-appel sur votre serveur / adresse URL pour vérifier les options autorisées. C’est la demande “OPTIONS” à laquelle votre serveur ne répond pas en conséquence. Si cet appel OPTIONS est répondu correctement, un deuxième appel est effectué, qui est la requête “POST” avec le contenu json.

    Cela se produit uniquement lors d’un appel interdomaine. Dans votre cas, appeler ‘ http://localhost:16329/Hello ‘ au lieu d’appeler un chemin d’URL sous le même domaine ‘/ Hello’

    Si vous envisagez de passer un appel interdomaine, vous devez améliorer votre classe de service de repos avec une méthode annotée, qui prend en charge une requête http “OPTIONS”. C’est l’implémentation Java correspondante:

     @Path("/rest") public class RestfulService { @POST @Path("/Hello") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.TEXT_PLAIN) public ssortingng HelloWorld(ssortingng name) { return "hello, " + name; } //THIS NEEDS TO BE ADDED ADDITIONALLY IF MAKING CROSS-DOMAIN CALLS @OPTIONS @Path("/Hello") @Produces(MediaType.TEXT_PLAIN+ ";charset=utf-8") public Response checkOptions(){ return Response.status(200) .header("Access-Control-Allow-Origin", "*") .header("Access-Control-Allow-Headers", "Content-Type") .header("Access-Control-Allow-Methods", "POST, OPTIONS") //CAN BE ENHANCED WITH OTHER HTTP CALL METHODS .build(); } } 

    Donc, je suppose que dans .NET, vous devez append une méthode supplémentaire annotée avec

     [WebInvoke( Method = "OPTIONS", UriTemplate = "Hello", ResponseFormat = WebMessageFormat.)] 

    où les en-têtes suivants sont définis

     .header("Access-Control-Allow-Origin", "*") .header("Access-Control-Allow-Headers", "Content-Type") .header("Access-Control-Allow-Methods", "POST, OPTIONS") 

    Si vous utilisez ceci:

     contentType: "application/json" 

    AJAX n’enverra pas les parameters GET ou POST au serveur …. ne sais pas pourquoi.

    Il m’a fallu des heures pour l’apprendre aujourd’hui.

    Utilisez simplement:

     $.ajax( { url : 'http://blabla.com/wsGetReport.php', data : myFormData, type : 'POST', dataType : 'json', // contentType: "application/json", success : function(wsQuery) { } } ) 

    J’ai eu la solution pour envoyer les données JSON par requête POST via jquery ajax. J’ai utilisé le code ci-dessous

      var data = new Object(); data.p_clientId = 4; data = JSON.ssortingngify(data); $.ajax({ method: "POST", url: "http://192.168.1.141:8090/api/Client_Add", data: data, headers: { 'Accept': 'application/json', 'Content-Type': 'text/plain' } }) .done(function( msg ) { alert( "Data Saved: " + msg ); }); }); }); 

    J’ai utilisé 'Content-Type': 'text/plain' dans 'Content-Type': 'text/plain' en-tête pour envoyer les données brutes json.
    Parce que si nous utilisons Content-Type: 'application/json' les méthodes de demande sont converties en OPTION, mais en utilisant Content-Type: 'test/plain' la méthode n’est pas convertie et rest en tant que POST. J’espère que cela aidera quelqu’un.