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


400

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

ingrese la descripción de la imagen aquí

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


3
Este problema también puede aparecer si el reuqest no se envió debido al cambio de dominio, por ejemplo, al enviar datos a través de ajax desde www.domain.tld a domain.tld o viceversa.
Andre Baumeier

@wvega Hay un problema similar publicado en esta pregunta de SO pero no parece haber ninguna explicación posible para este problema de Encabezados Provisionales Enviados . ¿Alguna solución concreta para esto? ¡realmente molesto! Publiqué esta pregunta hace algún tiempo.
webblover

1
@webblover Hay una buena explicación de wvega. Y en realidad no estaba buscando una solución. Tenía curiosidad acerca de una razón.
Salvador Dali

Me ayudó cuando lo chrome://flags/#site-isolation-trial-opt-out
apagué

Lea mi respuesta, no es tan complicado como parece: stackoverflow.com/questions/21177387/…
csandreas1

Respuestas:


353

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.

77
La respuesta de Shazz es mejor. Verá este mensaje en el depurador cada vez que se recupere el recurso de la memoria caché del navegador sin preguntarle al servidor si el contenido ha cambiado.
Maor

44
Creo que ambas respuestas son correctas, cuentan dos lados de la misma historia. El mensaje se muestra cuando una solicitud está bloqueada o los recursos se cargan desde la memoria caché, pero también después de que se inicia cada solicitud y mientras el navegador espera una respuesta del servidor. Tan pronto como llega la respuesta, el mensaje desaparece y se muestran los encabezados reales.
Willington Vega

2
Si se redirige una página analizada principalmente, por ejemplo example.com/a -> 301-> example.com/b, y la página objetivo responde con 200, y luego hace clic en un inspector en la página objetivo / b para ver los datos del encabezado , los obtendrá, etiquetados con "Se muestran encabezados provisionales". Es correcto porque no analizó la página de destino directamente. Si lo hace, obtiene los datos del encabezado sin la etiqueta.
Evgeniy

1
Pude determinar que este era mi problema porque cuando hice lo anterior. Mi sitio https estaba llamando a un archivo css https que estaba haciendo una redirección 302 a una página http. La seguridad no permitía que el archivo se cargara y solo mostraba los encabezados provisionales.
Steropes

1
Hay una muy buena explicación de las múltiples razones por las que esto puede suceder: stackoverflow.com/questions/12009423/…
boldnik

112

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


61
No, 304 no modificado proviene del servidor en respuesta a una solicitud condicional. Si está cargando un recurso en caché y su navegador no tiene que ponerse en contacto con el servidor, no obtendrá un 304 no modificado o ningún estado HTTP porque no se realizará una solicitud HTTP.
thomasrutter

77
Esto funciona para mí, cuando vi "Se muestran encabezados provisionales" en el panel del depurador, el código de estado de la solicitud era "200 OK (de caché)"
richie

3
Vi esto con una respuesta del trabajador de servicio, así que creo que al menos en algunos casos, tienes razón sobre la respuesta de caché :)
jacoballenwood

44
Apago el caché en las herramientas de desarrollo y sigo recibiendo este mensaje. El estado de todos los archivos es 200, no "(desde caché)". Por lo tanto, a veces puede deberse a la memoria caché, pero ciertamente no siempre.
Ralf

Está cargando datos de la memoria caché en mi caso.
Aviv Lo

40

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

ingrese la descripción de la imagen aquí

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


44
Pude hacer que esto funcionara solo con "Habilitar servicio de red" y "Ejecuta el servicio de red en proceso".
smalone

Acabo de desactivar el aislamiento del sitio y eso funcionó para mí.
Ashrith

3
Esto funcionó en Chrome normal (v74), sin embargo, a la última versión de Chrome Canary (v76) ahora le falta el indicador "# network-service" ... No puedo hacer que esto funcione en Canary sin él.
rico

Vi este problema en ambos localhost:8080y google.com(!?). La desactivación del aislamiento del sitio solucionó google.com, pero no localhost. Deshabilitar solo las otras dos opciones lo solucionó para todos los casos.
BlueRaja - Danny Pflughoeft

Solo tuve que desactivar esto: chrome: // flags / # site-isolated-trial-opt-out
Илья Зеленько

25

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.


2
Esa es la política del mismo origen del navegador: su página web y los recursos que está leyendo deben estar en el mismo puerto. developer.mozilla.org/en-US/docs/Web/Security/…
r3m0t

1
Genial, gracias por la ayuda. Estoy usando el servidor de desarrollo webpacks y pude agregar una regla de reescritura. '/graphql': { target: 'http://10.10.1.38:4000', changeOrigin: true }
James Harrington

Del mismo modo, resolví este problema agregando "proxy": "http://192.168.98.110:1234"a mi package.jsonen un proyecto create-react-app. A diferencia de la respuesta, no estoy usando HTTPS en ninguna parte del desarrollador, pero esto fue necesario porque mi aplicación y mi API están en diferentes IP.
chrishiestand

16

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.


1
Si sus solicitudes no están bloqueadas (200 OK), solo sucede con las solicitudes CORS, y el encabezado que falta es Cookie , desea verificar esta respuesta. Gracias, @onlynone
semako

@semako, ¿puedes explicar esto con un poco más de detalle? Me encuentro con un problema similar, pero no entiendo completamente por qué. Para obtener más información, consulte mi publicación más reciente. gracias.
Adn bps

12

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.


12

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.


6

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


Me encontré con el mismo tipo de problema, no había ningún error tipográfico, pero tenía un script que recargaba la página antes de que se disparara / completara la POST.
Raindal

4

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 .


Inhabilité HSTS y los encabezados originales aparecieron nuevamente. ¡Gracias!
kenberkeley

3

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


2

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.


2

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


2

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.


PHP Workers podría ser algo para usted
Bartłomiej Zalewski

2

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.


2

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


Sí, para mí, faltan permisos al usar una entrada de archivo para la solicitud.
phil294

2

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


1
Mi caso fue que el encabezado de autorización era demasiado largo
Agorilla

1

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.


Traté de encresparme, y recibí 60. de esta respuesta descubrí la cadena que faltaba en la instalación de SSL. agregue cadena y el problema desapareció. gracias amigo! utilice esto para verificar: curl -s -D- https: // <yourcomain.com>
apis17

1

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.


1

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.


Acabo de tener un problema similar en el que un video html5 no se cargaba cuando las herramientas de desarrollo de Chrome estaban abiertas, ya que mantengo 'Desactivar caché (mientras DevTools está abierto)' habilitado. Deshabilitar la configuración resolvió el problema.
Ant12

1

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.


1

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.


1

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.


1

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.


1

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.


0

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    
});

0

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
}

0

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.


0

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.


0

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.


0

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.