No se puede establecer el tipo de contenido en ''application/json'' en jQuery.ajax

content-type wcf-rest

Question

Cuando tengo este código

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

en Fiddler puedo ver la siguiente solicitud sin procesar

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

Pero lo que intento es establecer el tipo de contenido de application / x-www-form-urlencoded a application / json . Pero este código

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

Genera una solicitud extraña (que puedo ver en 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

¿Porqué es eso? ¿Qué es OPCIONES cuando debería ser POST allí? ¿Y dónde está mi tipo de contenido configurado para application / json? Y los parámetros de solicitud se han ido por alguna razón.

ACTUALIZACIÓN 1

En el lado del servidor, tengo un servicio RESTful realmente simple.

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

Pero por alguna razón no puedo llamar a este método con parámetros.

ACTUALIZACIÓN 2

Perdón por no responder tanto tiempo.

He agregado estos encabezados a la respuesta de mi servidor

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

No ayudó, tengo el método no permitido error del servidor.

Esto es lo que dice mi violinista

Entonces, ahora puedo estar seguro de que mi servidor acepta POST, GET, OPTIONS (si los encabezados de respuesta funcionan como espero). Pero, ¿por qué "Método no permitido"?

En la respuesta de WebView desde el servidor (puede ver la respuesta Raw en la imagen de arriba) se ve así

Answer 1

Encontré la solución para este problema here . No se olvide de permitir OPCIONES verbales en el controlador del servicio de la aplicación IIS.

Funciona bien. Gracias André Pedroso. :-)

Answer 2

Entonces, todo lo que necesita hacer para que esto funcione es agregar:

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

como un campo para su solicitud de publicación y funcionará.

Answer 3

Obtuve la solución para enviar los datos JSON por solicitud POST a través de jquery ajax. Utilicé el código siguiente

 var data = new Object();
data.p_clientId = 4;
data = JSON.stringify(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 );
});
});
});

Usé ''Content-Type'': ''text/plain'' en el encabezado para enviar los datos raw json.
Porque si usamos Content-Type: ''application/json'' los métodos de solicitud se convierten a OPTION, pero usando Content-Type: ''test/plain'' el método no se convierte y permanece como POST. Espero que esto ayude a alguien.

Answer 4

Parece que eliminar http:// de la opción url garantiza que se envíe el encabezado HTTP POST correcto.

No creo que necesite calificar completamente el nombre del host, solo use una URL relativa como la siguiente.

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

Un ejemplo mío que funciona:

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

Posiblemente relacionado: jQuery $ .ajax (), $ .post enviando "OPTIONS" como REQUEST_METHOD en Firefox

Editar: Después de investigar un poco más, descubrí que el encabezado OPTIONS se utiliza para averiguar si la solicitud del dominio de origen está permitida. Usando el violín, agregué lo siguiente a los encabezados de respuesta de mi servidor.

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

Una vez que el navegador recibió esta respuesta, envió la solicitud POST correcta con los datos json. Parecería que el tipo de contenido urlencoded de forma predeterminada se considera seguro y, por lo tanto, no se somete a las comprobaciones de dominio cruzadas adicionales.

Parece que deberá agregar los encabezados mencionados anteriormente a la respuesta de su servidor a la solicitud de OPCIONES. Por supuesto, debe configurarlos para permitir solicitudes de dominios específicos en lugar de todos.

Usé el siguiente jQuery para probar esto.

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

Referencias

• http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
• http://enable-cors.org/
• https://developer.mozilla.org/en/http_access_control

Answer 5

Puedo mostrarte cómo lo usé

 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.stringify(param),
success: function (msg) {
if (msg != null) {
return msg.URL;
}
}
});
}

Answer 6

Reconocí esas pantallas, estoy usando CodeFluentEntities, y tengo una solución que también funcionó para mí.

Estoy usando esa construcción:

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

como puedes ver, si uso

contentType: "",

o

contentType: "text/plain", //chrome

Todo funciona bien

No estoy 100% seguro de que sea todo lo que necesitas, porque también he cambiado los encabezados.

Answer 7

Si usas esto:

contentType: "application/json"

AJAX no enviará parámetros GET o POST al servidor ... no sé por qué.

Me llevó horas aprenderlo hoy.

Solo usa:

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

Answer 8

Tuve el mismo problema. Estoy ejecutando una aplicación de reposo de Java en un servidor jboss. Pero creo que la solución es similar en una aplicación web ASP .NET.

Firefox hace una llamada previa a su servidor / URL de reposo para verificar qué opciones están permitidas. Esa es la solicitud de "OPCIONES" a la que su servidor no responde en consecuencia. Si se responde a esta llamada de OPCIONES, se realiza una segunda llamada que es la solicitud real "POST" con contenido json.

Esto solo ocurre cuando se realiza una llamada entre dominios. En su caso, llame a '' http://localhost:16329/Hello '' en lugar de llamar a una ruta url bajo el mismo dominio ''/ Hello''

Si tiene la intención de realizar una llamada de dominio cruzado, tiene que mejorar su clase de servicio de descanso con un método anotado, admite una solicitud HTTP de "OPCIONES". Esta es la implementación según java:

@Path("/rest")
public class RestfulService {
@POST
@Path("/Hello")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.TEXT_PLAIN)
public string HelloWorld(string 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();
}
}

Así que supongo que en .NET tienes que agregar un método adicional anotado con

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

donde se establecen los siguientes encabezados

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