java - ¿Por qué el navegador IE 11 tiene aleatoriamente Content-Length=0 para las solicitudes POST de AJAX de jQuery?

internet-explorer-11 waffle

Question

Estoy trabajando en la aplicación basada en Spring MVC.

Los siguientes son los detalles de mi entorno: - Java 1.8.0_162 (64 bit) , Spring 4.3.1 , Apache Tomcat 8.0.49 , Waffle-1.8.3 para SSO, jquery-1.11.3 y la Google Charts API .

Ponga el siguiente código JavaScript en uno de los archivos JS comunes: - $.ajaxSetup({ cache: false });

Las solicitudes POST jQuery AJAX realizadas al servidor funcionan perfectamente en los navegadores Mozilla y Chrome . Pero cuando se trata de un navegador IE 11 , las solicitudes POST jQuery AJAX funcionan sin fallar solo cuando la ventana se carga por primera vez. Luego falla al azar y una vez falla, las solicitudes subsiguientes también fallan.

Las siguientes son las instantáneas de la pestaña Red del navegador IE 11 :

1. EXITOSA POST ajax POST :

2. ERROR Ajax solicitud POST :

Ambas solicitudes tienen el objeto JSON en sus respectivos cuerpos de solicitud . Pero, el valor de la propiedad Content-Length es 416 (el total de caracteres del objeto JSON de cadena) para la solicitud exitosa y 0 para la falla. Para la solicitud POST fallida aleatoriamente y las solicitudes posteriores, Content-Length siempre es 0 , pero el objeto JSON calculado siempre está presente en el cuerpo de la solicitud. En cada solicitud, el objeto JSON se construye dinámicamente.

ACTUALIZACIÓN-1 (26 de marzo de 2018) A continuación se muestra la configuración de autenticación de Waffle AD definida en el archivo web.xml :

<filter>
<filter-name>SecurityFilter</filter-name>
<filter-class>waffle.servlet.NegotiateSecurityFilter</filter-class>
<init-param>
<param-name>principalFormat</param-name>
<param-value>fqn</param-value>
</init-param>
<init-param>
<param-name>roleFormat</param-name>
<param-value>both</param-value>
</init-param>
<init-param>
<param-name>allowGuestLogin</param-name>
<param-value>false</param-value>
</init-param>
<init-param>
<param-name>securityFilterProviders</param-name>
<param-value>
waffle.servlet.spi.NegotiateSecurityFilterProvider
</param-value>
</init-param>
<init-param>
<param-name>waffle.servlet.spi.NegotiateSecurityFilterProvider/protocols</param-name>
<param-value>
Negotiate
NTLM
</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>SecurityFilter</filter-name>
<url-pattern>/welcome.do</url-pattern>
</filter-mapping>

Solo 1 URL, es decir, /welcome.do (la URL inicial que carga la aplicación web) está configurada para invocar la autenticación SSO.

A continuación se muestra el código JavaScript que dispara las solicitudes AJAX:

function getData() {
let dashboardFilterParams=new DashboardFilterParams(<passing the arguments to this constructor>);
//alert(JSON.stringify(dashboardFilterParams));
//console.dir(dashboardFilterParams);
$.ajax({
url: str_THIS_WA_URL+"/xyz/abcdXYZ.do?httpReqType=ajaxReq",
data: JSON.stringify(dashboardFilterParams),
dataType: "json",
contentType: "application/json",
mimeType: "application/json",
type: "POST",
success:function(responseData){
if(responseData && "success"===responseData.reqResult) {
//populating tables & drawing charts using Google Charts JS API if successfully fetched the data
} else {
//showing error message
}
},
error:function(data,status,er) {
showTheMessage("danger","Error getting data");
console.log("error: "+JSON.stringify(data)+"/n status: "+status+"/n er:"+er);
}
});
}

Detalles de la versión de IE 11 :

Además, estoy usando la API de Google Charts para representar gráficos en la página. Para lo cual las solicitudes se envían al servidor de la API de Google Charts. ¿Tiene este efecto en el navegador IE?

¿Cuál es la solución para que funcione en el navegador IE 11 ?

Respuestas a las preguntas de Federico Klez Culloca en la sección de comentarios:

1. Ningún error en el lado de la solicitud (cliente). Pero la respuesta del servidor dice que The request sent by the client was syntactically incorrect . y los encabezados de respuesta Response HTTP/1.1 400 Bad Request .

2. No hay ninguna diferencia absoluta en los contenidos del cuerpo de la solicitud.

3. La str_THIS_WA_URL variable apunta al mismo dominio que la aplicación web, es decir, las solicitudes AJAX están dentro del dominio actual.

Agregar la marca de tiempo (en la sugerencia de shawn en la sección de comentarios a continuación) a la URL no solucionó el problema.

Answer 1

IE hace esto como una optimización porque espera que el servidor responda con un desafío de credenciales HTTP / 401 y sería un desperdicio transmitir el cuerpo dos veces.

En su caso, ya que /welcome.do está asegurado con NTLM, IE ahora asume que / y todo lo que está debajo es parte del espacio de protección asegurado y, por lo tanto, aplica la optimización POST sin cuerpo a todo.

Una solución sería mover /welcome.do a /secured/welcome.do y asegurarse de que ningún recurso no /secured esté bajo /secured .

Más detalles aquí: autenticación de desafío-respuesta y publicaciones de longitud cero .