google chrome - tools - "PRECAUCIÓN: se muestran los encabezados provisionales" en el depurador de Chrome

javascript console chrome

Question

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

Se muestran los encabezados provisionales de precaución.

Encontré algo posiblemente relevante, el Panel de red: agregue precaución sobre los encabezados de solicitudes provisionales , pero no lo entendí completamente. Se pueden encontrar preguntas relacionadas con las solicitudes de bloqueo de Chrome y XMLHttpRequest no se puede 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í.

Answer 1

Aquí hay otra solución.

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

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

Answer 2

Corrí 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 activarlo en Configuración de las herramientas del desarrollador "Deshabilitar caché (cuando DevTools está abierto)". Y eso hizo el encanto.

Answer 3

Creo que sucede cuando no se envía la solicitud real. Por lo general, sucede cuando se está cargando un recurso en caché.

Answer 4

Dudo que mi respuesta llegue a tiempo para ayudarte, pero a otros les puede resultar útil. Experimenté un problema similar con un script de 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 dispararse. Corregí el error tipográfico y funcionó perfectamente bien para mí.

Answer 5

El mensaje "Precaución: se muestran los encabezados provisionales" se puede mostrar cuando el sitio web alojado en HTTPS invoca llamadas a WebApi alojadas en HTTP. Puede comprobar todo si todos sus Api''s son HTTPS. El navegador impide hacer una llamada a un recurso inseguro. Puede ver un mensaje similar en su código cuando use la API FETCH para hacer un 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.

Answer 6

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 encontré la extensión que estaba bloqueando mi recurso fue a través de la herramienta net-internals en Chrome:

• Escribe chrome://net-internals en la barra de direcciones y pulsa enter.
• Abra la página que está mostrando 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.

Answer 7

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

Answer 8

Encontré este problema y logré identificar una causa específica, que no se menciona arriba 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 mientras estoy eliminando una cookie de sesión de la API

Específicamente, mi situación fue: la solicitud POST, con las credenciales al puerto 8081 provocó el mensaje "PRECAUCIÓN: se muestran los encabezados provisionales" en el inspector y, por supuesto, también se bloqueó la solicitud.

Mi solución fue configurar Apache para que pase la solicitud desde el puerto SSL habitual de 443 al puerto SSL de nodo de 8081 (el nodo tiene que 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 de SSL a puertos SSL no convencionales, pero quizás su mensaje de error podría ser más específico.

Answer 9

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

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

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

Answer 10

Eso podría deberse a que enviaste una solicitud de Ajax, pero ahora mismo pasas de una página a otra usando location.href o algo así. Así que la solicitud de vista previa fue fallida.

Answer 11

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 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 los caracteres no válidos en el mensaje de error (descrito aquí http://aspnetwebstack.codeplex.com/workitem/1386 ) que resultó en encabezados de respuesta corruptos.

Answer 12

Este mensaje puede ocurrir cuando el sitio web está protegido usando 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 de HTTPS como sslstrip .

Answer 13

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

Answer 14

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

Answer 15

Esto me estaba sucediendo, cuando tenía un enlace de descarga y, después de hacer clic en él, también estaba intentando capturar 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 establecí un target = "_ blank" para evitar este problema.

Answer 16

Esto también puede suceder 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á arreglado en Chrome 68, pero estoy ejecutando Chrome 68 y todavía tengo el problema.

Answer 17

He tenido este problema recientemente (hoy de hecho) en el que he recibido una llamada de AJAX al servidor y Chrome dispara el mensaje "Precaución: se muestran los encabezados provisionales". En las secuencias de comandos de PHP del lado del servidor, hay consultas de MySQL que pueden ser casi instantáneas o tardar 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 consumen mucho tiempo (hasta unos pocos segundos en total) e impiden que se devuelva la respuesta.

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 ... por lo tanto, el retraso de la respuesta de la iteración a través de un bucle de consultas ALTER TABLE.

Answer 18

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

Answer 19

Me encontré con este problema con una llamada AJAX que nunca se completaría. Seguí el consejo de wvega y la sugerencia sobre la depuración con chrome://net-internals para determinar finalmente otro controlador de eventos de click en la página, escuchando en un nodo primario, lo que provocó que el navegador navegue 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 cancele la solicitud AJAX en curso (iniciada a través de un controlador de submit en el form ).

Answer 20

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 se olvida de tratar con la solicitud de OPTIONS , 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 inicialización de los axios , que es de 5000 milisegundos. Por lo tanto, no se pudo enviar la solicitud real, y luego me encontré con los provisional headers are shown problema.
Solución: cuando se trata de la solicitud de OPTIONS , la API de back-end 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.

Answer 21

Otro posible escenario que he visto: la misma solicitud se está enviando nuevamente después de unos milisegundos (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 solo de varios milisegundos.

Answer 22

Recibí este error cuando intenté imprimir una página en una ventana emergente. El cuadro de diálogo Imprimir se mostró y aún está 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 intenté hacer clic en otro enlace.

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

Answer 23

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

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

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

Answer 24

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

Answer 25

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é y probé con diferentes navegadores. Nada ayudó.

finalmente, he descubierto que la API estaba intentando devolver un enorme 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.

Answer 26

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.

Answer 27

Usa este código puño de tu código:

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

Esto funciona para mi

Answer 28

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.

Answer 29

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

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

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