"PRECAUCIÓN: se muestran encabezados provisionales" en el depurador de Chrome

Noté un extraño mensaje de precaución al mirar los recursos descargados usando el inspector de Google Chrome ( F12):

Precaución se muestran encabezados provisionales

Encontré algo posiblemente relevante, Panel de red: agregue precaución sobre los encabezados de solicitud provisionales , pero no pude entenderlo completamente. Se pueden encontrar preguntas relacionadas. Las solicitudes de bloque de Chrome y XMLHttpRequest no se pueden cargar. Los recursos descargados muestran precaución: se muestran los encabezados provisionales .

Similar a la primera pregunta , mi recurso fue bloqueado, pero luego cargó automáticamente 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 siendo bloqueado por una extensión (AdBlock en mi caso).

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

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

Para las últimas versiones de Chrome

• Escriba chrome://net-export/en la barra de direcciones y presione enter.
• Iniciar la grabación. Y guarde el archivo de grabación en local.
• Abra la página que muestra problemas.
• Regresar a la red interna
• Puede ver el archivo de registro grabado aquí https://netlog-viewer.appspot.com/#import
• haga clic en eventos (###) y use el campo de texto para encontrar 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.

Para versiones anteriores de cromo

• Escriba chrome://net-internalsen 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 encontrar 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 ocurrir cuando está cargando un recurso en caché.

Para Chrome v72 + lo que me resolvió fue solo esto:

ir chrome://flags/y deshabilitar estas 3 banderas

• Deshabilitar el aislamiento del sitio
• Habilitar servicio de red
• Ejecuta el servicio de red en proceso

o puedes hacerlo desde la línea de comandos:

chrome --disable-site-isolation-trials --disable-features=NetworkService,NetworkServiceInProcess

¿Por qué sucede esto?

Parece que Google está refactorizando su motor Chromium en una estructura modular, donde los diferentes servicios se separarán en módulos y procesos independientes. A este proceso lo llaman servicificación. El servicio de red es el primer paso, el servicio de interfaz de usuario, el servicio de identidad y el servicio del dispositivo están llegando. Google proporciona la información oficial en el sitio del proyecto Chromium .

¿Es peligroso cambiar eso?

Un ejemplo es la creación de redes: una vez que tenemos un servicio de red, podemos optar por ejecutarlo fuera del proceso para una mejor estabilidad / seguridad, o en proceso si tenemos recursos limitados . fuente

Encontré 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 pila js completa, un front-end angular y un back-end de nodo en SSL, y la API está en un dominio diferente que se ejecuta en el puerto 8081, por lo que estoy haciendo solicitudes CORS y con credenciales a medida que descarto una cookie de sesión de la API

Así que específicamente mi escenario fue: solicitud POST, con credenciales al puerto 8081 causó el mensaje "PRECAUCIÓN: se muestran encabezados provisionales" en el inspector y, por supuesto, también bloqueó la solicitud por completo.

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

Esto también puede suceder (solo para solicitudes de origen cruzado) 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-outChrome 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á arreglado en Chrome 68, pero estoy ejecutando Chrome 68 y todavía tengo el problema.

Los recursos empujados HTTP / 2 generarán Provisional headers are shownen el inspector la misma teoría que @wvega publicó en su respuesta anterior .

por ejemplo: dado que el servidor empujó los recursos al cliente ( antes de que el cliente los solicitara ), el navegador tiene los recursos en caché y, por lo tanto, el cliente nunca hace / necesita solicitudes; Entonces porque...

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

Mi situación está relacionada con el origen cruzado .
Situación: el navegador envía la OPTIONSsolicitud antes de enviar la solicitud real como GETo POST. El desarrollador de back-end se olvida de atender la OPTIONSsolicitud, dejándola pasar por el código de servicio, haciendo que el tiempo de procesamiento sea demasiado largo. Más largo que el tiempo de espera que escribí en la axiosinicialización, que es de 5000 milisegundos. Por lo tanto, la solicitud real no se pudo enviar, y luego encontré el provisional headers are shownproblema.
Solución: cuando se trata de una OPTIONSsolicitud, la API de backend 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.

Dudo que mi respuesta llegue a tiempo para ayudarlo, pero a otros les puede resultar ú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 disparar la publicación. Había escrito href = " javacsript:; " (invirtiendo la 's' y la 'c') ... esto provocó que el script intentara actualizar la página mientras la publicación intentaba activarse. corrigió el error tipográfico y funcionó perfectamente bien para mí.

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

Eso podría deberse a que envió una solicitud de Ajax, al mismo tiempo que salta su página a otra usando location.href o algo así. Entonces la solicitud anterior falló.

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

En mi caso, la solicitud se envió correctamente al servidor, el código del lado del servidor produjo un error y mi manejo de errores 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 (descrito aquí http://aspnetwebstack.codeplex.com/workitem/1386 ) que resultó en encabezados de respuesta corruptos.

Me encontré con este problema con una llamada AJAX que nunca se completaría. Seguí el consejo y la sugerencia de wvega sobre la depuración chrome://net-internalspara eventualmente determinar que otro clickcontrolador de eventos en la página, escuchando en un nodo principal, estaba causando que el navegador navegara a la misma URL (por lo que no se notaba fácilmente).

La solución consistía en agregar event.stopPropagation()un clickcontrolador en el botón de envío del formulario para evitar que el clic aumentara el DOM y cancelara la solicitud de AJAX en curso (iniciada mediante un submitcontrolador en el form).

Esto surgió recientemente (de hecho, hoy) donde recibí una llamada de AJAX al servidor y Chrome disparó la "Precaución: se muestran los encabezados provisionales". En el script PHP del lado del servidor, hay consultas MySQL que pueden ser bastante instantáneas o tomar unos segundos dependiendo del escenario dado. La respuesta de mi servidor no se envía de vuelta al navegador hasta que se completen las consultas. Descubrí que recibo este error solo cuando se realizan consultas que requieren mucho tiempo (hasta unos segundos en total) y evito que la respuesta se envíe de vuelta.

Mi escenario implica la posibilidad muy rara de tener que alterar una tabla agregando / eliminando cientos de columnas para la salida del modelo meteorológico ... por lo tanto, el retraso de la respuesta de iterar a través de un ciclo de consultas ALTER TABLE.

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

e.preventDefault();

o

return false;

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

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

Este problema se me ocurrió cuando estaba enviando un encabezado de autorización HTTP no válido. Olvidé codificarlo en base64.

Encontré esto y desapareció cuando cambié de https a http. Los certificados SSL que utilizamos en dev no son verificados por un tercero. Son solo certificados de desarrollo generados localmente.

Las mismas llamadas funcionan bien en Chrome Canary y Firefox. Estos navegadores no parecen ser tan estrictos con respecto al certificado SSL como lo es Chrome. Las llamadas fallarían en Chrome con el mensaje "PRECAUCIÓN: encabezados provisionales ...".

Creo / espero que cuando usemos un certificado SSL legítimo en etapa y producción, ya no veremos este comportamiento en Chrome.

Solo tirando mis dos centavos. Estoy escribiendo una aplicación web usando solicitudes CORS y un servicio web RESTful completo. He encontrado que Chrome arrojará este error cuando tenga una excepción no manipulada o un error PHP lanzado. Solo en caso de que alguien más se encuentre con el problema. Descubrí que cuando esto sucede, puedo iniciar la aplicación de Chrome "Postman - Rest Client" y ejecutar exactamente la misma solicitud, pero en la aplicación de Chrome obtendré el error de PHP que se está lanzando en lugar de este error no descriptivo.

Ejecuté este problema cuando intenté cargar main.js para require js por segunda vez después de realizar cambios como resultado de un error. Acabo de activar en Configuración de herramientas de desarrollador "Deshabilitar caché (cuando DevTools está abierto)". y eso hizo el encanto.

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

Esto me estaba sucediendo, cuando tenía un enlace de descarga y después de hacer clic en él, intentaba también captar el clic con jquery y enviar una solicitud de ajax. El problema fue porque cuando hace clic en el enlace de descarga, abandona la página, aunque no lo parezca. Si no hubiera transferencia de archivos, vería la página solicitada. Así que configuré un target = "_ blank" para evitar este problema.

Recibí este error cuando intenté imprimir una página en una ventana emergente. Se mostró el cuadro de diálogo de impresión y todavía estaba esperando 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 segundo plano mostrando el mensaje PRECAUCIÓN Los encabezados provisionales se muestran cuando intento hacer clic en otro enlace.

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

Vi que esto ocurría cuando la cantidad de conexiones a mi servidor excedía el límite máximo de 6 conexiones por servidor de Chrome.

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

Aquí hay otra solución.

Si encuentra este problema con la llamada $ ajax (), agregue http://antes de que su servidor solucione 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á intentando devolver un JsonResulten su controlador, asegúrese de agregarlo JsonRequestBehavior.AllowGetal Jsonmétodo. Eso me lo arregló.

public JsonResult GetTaskSubCategories(int id)
{
    var subcategs = FindSubCategories(id);

    return Json(subcategs, JsonRequestBehavior.AllowGet);  //<-- Notice it has two parameters
}

El mensaje "Precaución: se muestran encabezados provisionales" se puede mostrar cuando el sitio web alojado en HTTPS invoca una llamada a WebApi alojado en HTTP. Puede verificar todo si todas sus Api son HTTPS. El navegador evita hacer una llamada a un recurso inseguro. Puede ver un mensaje similar en su código cuando usa la API FETCH para dominar 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 ocurriendo en una sola solicitud de obtención. Intenté eliminar adblock, intenté borrar el caché e intenté con diferentes navegadores. Nada ayudó

Finalmente, me di cuenta de 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.

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

En mi caso, la causa fue la extensión AdBlock.

La solicitud al servidor se realizó y recibí la respuesta, pero no pude ver las cookies de solicitud debido a que se muestran "encabezados provisionales ..." en las herramientas de desarrollo. Después de deshabilitar AdBlock para el sitio, la advertencia desapareció y las herramientas de desarrollo comenzaron a mostrar las cookies nuevamente.

Para que el cambio surta efecto, también fue necesario cerrar las herramientas de desarrollo y actualizar la página