“PRECAUCIÓN: los encabezados provisionales se muestran” en el depurador de Chrome

Observé un extraño mensaje de precaución cuando miraba los recursos descargados usando Google chrome inspector (F12):

Se muestran encabezados provisionales de precaución

enter image description here

Encontré algo posiblemente relevante, el Panel de Red: agregue precaución sobre los encabezados de solicitud provisional , pero no pude entenderlo por completo. Se pueden encontrar preguntas relacionadas Las solicitudes de locking de Chrome , así como XMLHttpRequest no se pueden cargar. Los recursos descargados muestran precaución: se muestran los encabezados provisionales .

Al igual que en la primera pregunta , mi recurso fue bloqueado, pero luego automáticamente cargó el mismo recurso. A diferencia de la segunda pregunta , no quiero arreglar nada; Quiero saber qué significa este mensaje y por qué lo recibí.

    El recurso podría estar bloqueado por una extensión (AdBlock en mi caso).

    El mensaje está allí porque nunca se realizó la solicitud para recuperar ese recurso, por lo que los encabezados que se muestran no son reales. Como se explicó en el problema al que se hace referencia, los encabezados reales se actualizan cuando el servidor responde, pero no hay respuesta si la solicitud se bloqueó.


    La forma en que encontré acerca de la extensión que estaba bloqueando mi recurso fue a través de la herramienta net-internals en Chrome:

    • Escriba chrome://net-internals en la barra de direcciones y presione enter.
    • Abra la página que muestra problemas.
    • Regrese a net-internals, haga clic en eventos (###) y use el campo de texto para buscar el evento relacionado con su recurso (use partes de la URL).
    • Finalmente, haga clic en el evento y vea si la información que se muestra le dice algo.

    Creo que sucede cuando la solicitud real no se envía. Suele suceder cuando estás cargando un recurso en caché.

    Me encontré con este problema, y ​​logré identificar una causa específica, que no se menciona anteriormente ni en las respuestas ni en la pregunta.

    Estoy ejecutando una stack completa de js, frontal angular y nodo posterior en SSL, y la API está en un dominio diferente que se ejecuta en el puerto 8081, así que estoy haciendo solicitudes CORS y conCredentials porque elimino una cookie de sesión de la API

    Así que específicamente mi escenario fue: la solicitud POST, con las referencias al puerto 8081, provocó el mensaje “PRECAUCIÓN: los encabezados provisionales se muestran” en el inspector y, por supuesto, bloquearon la solicitud todos juntos.

    Mi solución fue configurar apache para que el proxy pase la solicitud desde el puerto SSL habitual de 443 al puerto SSL del nodo de 8081 (el nodo debe estar en un puerto más alto ya que no se puede ejecutar como root en prod). Así que supongo que a Chrome no le gustan las solicitudes de SSL a los puertos SSL no convencionales, pero tal vez su mensaje de error podría ser más específico.

    Los recursos HTTP / 2 presionados producirán Provisional headers are shown en el inspector por la misma teoría que @wvega publicada en su respuesta anterior .

    Por ejemplo: dado que el servidor envió los recursos al cliente ( antes de que el cliente los solicitara ), el navegador tiene los recursos almacenados en la memoria caché y, por lo tanto, el cliente nunca hace / necesita una solicitud; Entonces porque…

    … los encabezados reales se actualizan cuando el servidor responde, pero no hay respuesta si la solicitud fue bloqueada.

    Dudo que mi respuesta llegue a tiempo para ayudarte, pero otros pueden encontrarla útil. Experimenté un problema similar con un script jQuery Ajax Post que creé.

    Resultó que tenía un error tipográfico en el atributo href de la etiqueta A que estaba usando para activar la publicación. He escrito href = ” javacsript:; ” (invirtiendo la ‘s’ y la ‘c’) … esto hizo que la secuencia de comandos intentara actualizar la página mientras la publicación intentaba disparar. corrigió el error tipográfico y funcionó perfectamente bien para mí.

    Este mensaje puede ocurrir cuando el sitio web está protegido mediante HSTS . Luego, cuando alguien se vincula a la versión HTTP de la URL, el navegador, como lo indica HSTS, no emite una solicitud HTTP, sino que internamente redirige al recurso HTTPS de forma segura. Esto es para evitar ataques de degradación de HTTPS como sslstrip .

    Me encontré con este problema con una llamada AJAX que nunca se completaría. Seguí el consejo de wvega y aconsejé sobre la depuración con chrome://net-internals para eventualmente determinar otro manejador de eventos click en la página, escuchando en un nodo padre, estaba causando que el navegador navegara a la misma URL (por lo que no fue fácil perceptible).

    La solución fue agregar event.stopPropagation() en un controlador de click en el botón de envío de formulario para evitar que el clic burbujee el DOM y se cancele la solicitud AJAX en progreso (iniciada a través de un controlador de submit en el form ).

    He tenido esto recientemente (de hecho) cuando recibí una llamada AJAX al servidor y Chrome desactivó “Precaución: se muestran los encabezados provisionales”. En el lado del servidor de secuencias de comandos PHP, hay consultas MySQL que pueden ser bastante instantáneas o demorar unos segundos según el escenario. La respuesta de mi servidor no se devuelve al navegador hasta que se completen las consultas. He descubierto que recibo este error solo cuando se realizan consultas que llevan mucho tiempo (hasta unos pocos segundos en total) y evitan que la respuesta se envíe de vuelta.

    Mi escenario implica la muy rara posibilidad de tener que modificar una tabla agregando / eliminando cientos de columnas para la salida del modelo meteorológico … de ahí el retraso de respuesta de iterar a través de un bucle de consultas ALTER TABLE.

    En mi caso, era solo una ruta de acceso falsa a un recurso (svg / img)

    Se me ocurrió este problema cuando estaba enviando un encabezado de Autorización HTTP no válido. Me olvidé de codificarlo en base64.

    Mi situación está relacionada con el origen cruzado .
    Situación: el navegador envía la solicitud de OPTIONS antes de enviar la solicitud real como GET o POST . El desarrollador de Backend olvida tratar con la solicitud OPTIONS , permitiéndole pasar por el código de servicio, lo que hace que el tiempo de procesamiento sea demasiado largo. Más tiempo que la configuración de tiempo de espera que escribí en la inicialización de los axios , que es de 5000 milisegundos. Por lo tanto, la solicitud real no se pudo enviar, y luego me encontré con los provisional headers are shown problemas.
    Solución: cuando se trata de la solicitud de OPTIONS , la API del servidor solo devuelve el resultado, hace que la solicitud sea más rápida y la solicitud real se puede enviar antes del tiempo de espera.

    Este mensaje de precaución también se produce si la respuesta no es válida y, por lo tanto, se elimina por el navegador.

    En mi caso, la solicitud se envió correctamente al servidor, el código del lado del servidor produjo un error y mi manejo de error personalizado devolvió el mensaje de error en el campo de mensaje de estado HTTP. Pero este error no se recibió en el lado del cliente, debido a caracteres no válidos en el mensaje de error (que se describe aquí http://aspnetwebstack.codeplex.com/workitem/1386 ), que dio como resultado encabezados de respuesta corruptos.

    Me encontré con esto y desapareció cuando cambié de https a http. Los certificados SSL que utilizamos en dev no son verificados por un tercero. Son solo certificadores de generación local.

    Las mismas llamadas funcionan bien en Chrome Canary y Firefox. Estos navegadores no parecen ser tan estrictos sobre el certificado SSL como Chrome. Las llamadas fallarían en Chrome con el mensaje “PRECAUCIÓN: encabezados provisionales …”.

    Creo / espero que cuando usemos un certificado legítimo de SSL en la etapa y prod, ya no veremos este comportamiento en Chrome.

    Ejecuté este problema cuando intenté cargar main.js para requerir js por segunda vez después de realizar cambios como resultado de un error. Acabo de activar las configuraciones de Herramientas del desarrollador “Desactivar caché (cuando DevTools está abierto)”. y eso hizo el encanto.

    Otro posible escenario que he visto: la misma solicitud exacta se envía nuevamente después de unos pocos milisegundos (muy probablemente debido a un error en el lado del cliente).
    En ese caso, también verá que el estado de la primera solicitud se “cancela” y que la latencia es de solo varios milisegundos.

    Esto estaba sucediendo para mí, cuando tenía un enlace de descarga y después de hacer clic en él también intentaba capturar el clic con jquery y enviar una solicitud de ajax. El problema se debe a que cuando hace clic en el enlace de descarga, está dejando la página, incluso si no se ve así. Si no hubiera transferencia de archivos, vería la página solicitada. Por lo tanto, establecí un objective = “_ en blanco” para evitar este problema.

    Recibí este error cuando traté de imprimir una página en una ventana emergente. El cuadro de diálogo de impresión se mostró y aún esperaba mi aceptación o cancelación de la impresión en la ventana emergente, mientras que en la página maestra también estaba esperando en el fondo el mensaje que muestra PRECAUCIÓN, los encabezados provisionales se muestran cuando trato de hacer clic en otro enlace.

    En mi caso, la solución fue eliminar window.print (); script que se estaba ejecutando en el de la ventana emergente para evitar el diálogo de impresión.

    Una razón común por la que esto sucede es si está rastreando un evento y no previene la acción predeterminada. Por ejemplo, si tiene un evento de clic, querrá incluir:

     e.preventDefault(); 

    o

     return false; 

    Si no lo hace, verá la advertencia de encabezados provisorios, así como un estado “cancelado” en la pestaña Red de su consola web.

    Vi que esto ocurría cuando el número de conexiones a mi servidor excedía el límite de conexiones máximas de Chrome de 6.

    Use este puño de código de su código:

     header('Cache-Control: no-cache, no-store, must-revalidate'); header('Pragma: no-cache'); header('Expires: 0'); 

    Esto funciona para mí

    Solo lanzando mis dos centavos. Estoy escribiendo una aplicación web usando solicitudes CORS y un servicio web RESTful completo. He encontrado que Chrome emitirá este error cuando tengo una excepción sin manos o un error de PHP lanzado. Solo en caso de que alguien más se encuentre con el problema. Descubrí que cuando esto sucede, puedo abrir la aplicación de Chrome “Postman – Rest Client” y ejecutar exactamente la misma solicitud, pero en la aplicación de Chrome realmente obtendré el error PHP que se lanza en lugar de este error no descriptivo.

    Aquí hay otra solución.

    Si encuentra este problema con la llamada $ ajax (), agregue http:// antes de que su servidor servidor resuelva su problema.

     var requestURL = "http://" + serverHost; $.ajax({ dataType: "json", url: requestURL, data: data, success: success }); 

    Si está desarrollando una aplicación Asp.Net Mvc y está tratando de devolver un JsonResult en su controlador, asegúrese de agregar JsonRequestBehavior.AllowGet al método Json . Eso lo solucionó para mí.

     public JsonResult GetTaskSubCategories(int id) { var subcategs = FindSubCategories(id); return Json(subcategs, JsonRequestBehavior.AllowGet); //< -- Notice it has two parameters } 

    Se puede mostrar el mensaje “Precaución: los encabezados provisionales” cuando el sitio web alojado en HTTPS invoca llamadas a WebApi alojado en HTTP. Puedes verificar todo si todas tus Api son HTTPS. El navegador evita hacer una llamada a un recurso inseguro. Puede ver un mensaje similar en su código cuando use la API FETCH para el dominio con HTTP.

    Contenido mixto: la página en ‘ https://website.com ‘ se cargó a través de HTTPS, pero solicitó un recurso inseguro ‘ http://webapi.com ‘. Esta solicitud ha sido bloqueada; el contenido debe ser servido a través de HTTPS.

    Tuve un problema similar con mi aplicación MEAN. En mi caso, el problema estaba sucediendo en una sola solicitud de obtención. Intenté eliminar Adblock, intenté borrar el caché y lo intenté con diferentes navegadores. Nada ayudó.

    finalmente, he descubierto que la API estaba tratando de devolver un gran objeto JSON. Cuando intenté enviar un objeto pequeño, funcionaba bien. Finalmente, he cambiado mi implementación para devolver un búfer en lugar de un JSON.

    Deseo que expressJS arroje un error en este caso.

    Los datos en caché eliminados del historial del navegador funcionan para mí.

    Este problema también ocurrirá al usar algunos paquetes como webpack-hot-middleware y abrir varias páginas al mismo tiempo. webpack-hot-middleware creará una conexión para cada página para escuchar los cambios de código y luego actualizar la página. Cada navegador tiene una limitación max-connections-per-server que es 6 para Chrome, por lo que si ya ha abierto más de 6 páginas en Chrome, la nueva solicitud se bloqueará allí hasta que cierre algunas páginas.

    Esto también puede ocurrir debido a una nueva característica llamada aislamiento del sitio

    Esta página detalla el problema y una solución alternativa . Que es ir a chrome://flags/#site-isolation-trial-opt-out en chrome y cambiar esa configuración a “Opt-out” y volver a cargar chrome.

    Es un problema conocido . Sin embargo, esa página dice que está arreglada en Chrome 68, pero estoy ejecutando Chrome 68 y todavía tengo el problema.

    Eso podría deberse a que enviaste una solicitud de Ajax, pero ahora saltas tu página a otra utilizando location.href o algo así. Entonces, la solicitud de vista previa falló.