“ATTENZIONE: le intestazioni provvisorie sono mostrate” nel debugger di Chrome

Ho notato uno strano messaggio di attenzione quando guardavo le risorse scaricate usando Google chrome inspector (F12):

Attenzione sono mostrate le intestazioni provvisorie

inserisci la descrizione dell'immagine qui

Ho trovato qualcosa di pertinente, Pannello di rete: aggiungere caucanvas sulle intestazioni delle richieste provvisorie , ma non ho potuto capirlo appieno. Domande correlate possono essere trovate richieste di blocchi di Chrome così come XMLHttpRequest non può caricare. Le risorse scaricate mostrano caucanvas: vengono mostrate le intestazioni provvisorie .

Simile alla prima domanda , la mia risorsa è stata bloccata, ma in seguito ha caricato automaticamente la stessa risorsa. A differenza della seconda domanda , non voglio sistemare nulla; Voglio sapere cosa significa questo messaggio e perché l’ho ricevuto.

La risorsa potrebbe essere bloccata da un’estensione (AdBlock nel mio caso).

Il messaggio è lì perché la richiesta di recuperare quella risorsa non è mai stata fatta, quindi le intestazioni mostrate non sono la cosa reale. Come spiegato nel problema a cui si fa riferimento, le intestazioni reali vengono aggiornate quando il server risponde, ma non c’è risposta se la richiesta è stata bloccata.


Il modo in cui ho trovato l’estensione che stava bloccando la mia risorsa era attraverso lo strumento net-internals in Chrome:

  • Digita chrome://net-internals nella barra degli indirizzi e premi invio.
  • Apri la pagina che mostra problemi.
  • Torna a net-internals, fai clic sugli eventi (###) e usa il campo di testo per trovare l’evento relativo alla tua risorsa (usa parti dell’URL).
  • Infine, fai clic sull’evento e guarda se le informazioni mostrate ti dicono qualcosa.

Credo che accada quando non viene inviata la richiesta effettiva. Solitamente accade quando si carica una risorsa memorizzata nella cache.

Ho riscontrato questo problema e sono riuscito a identificare una causa specifica, che non è menzionata sopra né nelle risposte né nella domanda.

Sto eseguendo uno stack js completo, un front-end angular e un back-end del nodo su SSL e l’API si trova su un dominio diverso in esecuzione sulla porta 8081, quindi sto facendo richieste CORS e withCredentials mentre sto facendo cadere un cookie di sessione dall’API

Quindi, in particolare, il mio scenario era: la richiesta POST, conCredentials alla porta 8081 causava il messaggio “ATTENZIONE: le intestazioni provvisorie sono mostrate” nell’ispettore e ovviamente bloccava la richiesta tutte insieme.

La mia soluzione era di impostare apache su proxy per passare la richiesta dalla solita porta SSL di 443 alla porta SSL del nodo 8081 (il nodo deve trovarsi su una porta superiore in quanto non può essere eseguito come root in prod). Quindi suppongo che a Chrome non piacciano le richieste SSL per le porte SSL non convenzionali, ma forse il loro messaggio di errore potrebbe essere più specifico.

Le risorse HTTP / 2 generate produrranno Provisional headers are shown nell’ispettore per la stessa teoria di @wvega pubblicata nella sua risposta sopra .

es .: poiché il server ha spinto le risorse sul client ( prima che il client le richiedesse ), il browser ha le risorse in cache e quindi il client non fa mai / richiede richieste; Così perchè…

… le intestazioni reali vengono aggiornate quando il server risponde, ma non c’è risposta se la richiesta è stata bloccata.

Dubito che la mia risposta sia in tempo per aiutarti ma altri potrebbero trovare utile. Ho riscontrato un problema simile con uno script jQuery Ajax Post che ho creato.

Si è scoperto che ho avuto un refuso nell’attributo href del tag A che stavo usando per sparare il post. Ho digitato href = ” javacsript:; ” (invertendo il ‘s’ e il ‘c’) .. questo ha causato lo script per cercare di aggiornare la pagina mentre il post stava tentando di sparare. corretto l’errore di battitura e ha funzionato perfettamente bene per me.

Questo messaggio può verificarsi quando il sito Web è protetto tramite HSTS . Quindi, quando qualcuno collega alla versione HTTP dell’URL, il browser, come indicato da HSTS, non invia una richiesta HTTP, ma reindirizza internamente alla risorsa HTTPS in modo sicuro. Questo per evitare attacchi downgrade HTTPS come sslstrip .

Mi sono imbattuto in questo problema con una chiamata AJAX che non sarebbe mai stata completata. Ho seguito il consiglio di wvega e mi sono soffermato sul debugging con chrome://net-internals per determinare eventualmente un altro gestore di eventi click nella pagina, ascoltando su un nodo genitore, stava facendo navigare il browser verso lo stesso URL (quindi non era facile evidente).

La soluzione consisteva nell’aggiungere event.stopPropagation() in un gestore di click sul pulsante di invio del modulo per impedire al clic di ribollire sul DOM e di annullare la richiesta AJAX in corso (avviata tramite un gestore di submit nel form ).

L’ho riscontrato molto recentemente (oggi infatti) in cui ho ricevuto una chiamata AJAX sul server e Chrome si spegne “Attenzione: vengono mostrate le intestazioni provvisorie.” Nello scripting PHP lato server, ci sono query MySQL che possono essere praticamente istantanee o richiedere qualche secondo a seconda dello scenario indicato. La mia risposta al server non viene rispedita al browser fino a quando le query non sono state completate. Ho riscontrato che ottengo questo errore solo quando si eseguono query che richiedono molto tempo (fino a pochi secondi in totale) e si impedisce che la risposta venga rispedita.

Il mio scenario implica la possibilità molto rara di dover modificare una tabella aggiungendo / rimuovendo centinaia di colonne per l’output del modello meteo … quindi il ritardo di risposta dall’iterazione di un ciclo di query ALTER TABLE.

Nel mio caso era solo un falso percorso impostato su una risorsa (svg / img)

Questo problema mi è accaduto quando stavo inviando un’intestazione di authorization HTTP non valida. Ho dimenticato di codificarlo in base64.

La mia situazione è legata alle origini .
Situazione: il browser invia la richiesta OPTIONS prima di inviare la richiesta reale come GET o POST . Lo sviluppatore di backend si dimentica di gestire la richiesta OPTIONS , lasciandola passare attraverso il codice del servizio, rendendo troppo lungo il tempo di elaborazione. Più a lungo dell’impostazione di timeout che ho scritto axios degli axios , che è di 5000 millisecondi. Pertanto, non è stato ansible inviare la richiesta reale e quindi ho riscontrato che le provisional headers are shown problemi.
Soluzione: quando si tratta della richiesta OPTIONS , l’API backend restituisce solo i risultati, rende la richiesta più veloce e la richiesta reale può essere inviata prima del timeout.

Questo messaggio di avvertenza si verifica anche se la risposta non è valida e quindi viene eliminata dal browser.

Nel mio caso la richiesta è stata inviata correttamente al server, il codice lato server ha quindi prodotto un errore e la mia gestione degli errori personalizzata ha restituito il messaggio di errore nel campo del messaggio di stato HTTP. Ma questo errore non è stato ricevuto sul lato client, a causa di caratteri non validi nel messaggio di errore (descritto qui http://aspnetwebstack.codeplex.com/workitem/1386 ) che ha provocato intestazioni di risposta corrotte.

Mi sono imbattuto in questo e è andato via quando sono passato da https a http. I certificati SSL che utilizziamo in dev non sono verificati da una terza parte. Sono solo sviluppatori sviluppati localmente.

Le stesse chiamate funzionano bene su Chrome Canary e Firefox. Questi browser non sembrano essere così rigidi riguardo al certificato SSL come Chrome. Le chiamate fallirebbero in Chrome con il messaggio “ATTENZIONE: intestazioni provvisorie …”.

Penso / spero che quando usiamo un certificato SSL legittimo in stage e prod, non vedremo più questo comportamento in Chrome.

Ho eseguito questo problema quando ho provato a caricare main.js per richiedere js per la seconda volta dopo aver apportato le modifiche come risultato dell’errore. Ho appena triggersto in Impostazioni strumenti di sviluppo “Disabilitare Cache (quando DevTools è aperto)”. e quello ha fatto il fascino.

Un altro scenario ansible che ho visto – la stessa identica richiesta viene inviata di nuovo solo dopo pochi millisecondi (molto probabilmente a causa di un bug nel lato client).
In questo caso vedrai anche che lo stato della prima richiesta è “cancellato” e che la latenza è solo di alcuni millisecondi.

Questo stava accadendo per me, quando avevo un link per il download e dopo aver cliccato su di esso stavo cercando anche di prendere il click con jquery e inviare una richiesta Ajax. Il problema era che quando si fa clic sul collegamento per il download, si esce dalla pagina, anche se non sembra così. Se non ci fosse il trasferimento di file, vedresti la pagina richiesta. Quindi ho impostato un target = “_ blank” per prevenire questo problema.

Ho ricevuto questo errore quando ho provato a stampare una pagina in un popup. La finestra di dialogo di stampa è stata mostrata ed è ancora in attesa della mia accettazione o cancellazione della stampa nel popup mentre nella pagina master era anche in attesa sullo sfondo che mostrava il messaggio CAUTELA le intestazioni provvisorie sono mostrate quando ho provato a fare clic su un altro collegamento.

Nel mio caso la soluzione era rimuovere il window.print (); script che era in esecuzione sul della finestra popup per impedire la finestra di stampa.

Un motivo comune che ciò accade è se si tiene traccia di un evento e non si impedisce l’azione predefinita. Ad esempio, se hai un evento click, dovrai includere:

 e.preventDefault(); 

o

 return false; 

In caso contrario, vedrai l’avviso delle intestazioni provvisorie e uno stato “annullato” nella scheda Rete della tua console web.

Ho visto che ciò si verificava quando il numero di connessioni al mio server superava il limite massimo di 6 connessioni per server di Chrome.

Usa questo codice pugno del tuo codice:

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

Questo funziona per me.

Sto solo lanciando i miei due centesimi. Sto scrivendo un’applicazione Web utilizzando le richieste CORS e un servizio web RESTful completo. Ho trovato che Chrome genererà questo errore quando ho un’eccezione non gestita o un errore PHP generato. Basta incidere qualcun altro si imbatte nel problema. Ho scoperto che, quando ciò accade, posso triggersre l’app Chrome “Postman – Rest Client” ed eseguire la stessa identica richiesta ma nell’app Chrome, in realtà, otterrò l’errore PHP che viene generato anziché questo errore non descrittivo.

Ecco un’altra soluzione.

Se si verifica questo problema con la chiamata $ ajax (), aggiungere http:// prima che il server host risolva il problema.

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

Se si sta sviluppando un’applicazione Asp.Net Mvc e si sta tentando di restituire un JsonResult nel controller, assicurarsi di aggiungere JsonRequestBehavior.AllowGet al metodo Json . Questo lo ha risolto per me.

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

“Attenzione: le intestazioni provvisorie sono mostrate” il messaggio può essere visualizzato quando il sito web ospitato su HTTPS richiama una chiamata a WebApi ospitato su HTTP. Puoi controllare tutto se tutte le tue Api sono HTTPS. Il browser impedisce di effettuare una chiamata a una risorsa non sicura. Puoi vedere un messaggio simile nel tuo codice quando usi FETCH API al dominio con HTTP.

Contenuto misto: la pagina su ” https://website.com ” è stata caricata su HTTPS, ma ha richiesto una risorsa non protetta ” http://webapi.com “. Questa richiesta è stata bloccata; il contenuto deve essere pubblicato su HTTPS.

Ho avuto un problema simile con la mia app MEAN. Nel mio caso, il problema stava accadendo in una sola richiesta di ottenere. Ho provato con la rimozione di adblock, provato a svuotare la cache e provato con diversi browser. Niente ha aiutato.

infine, ho capito che l’API stava cercando di restituire un enorme object JSON. Quando ho provato a inviare un piccolo object, funzionava perfettamente. Infine, ho cambiato la mia implementazione per restituire un buffer invece di un JSON.

Vorrei che expressJS lanci un errore in questo caso.

Cancella I dati memorizzati nella cache dalla cronologia del browser funzionano per me.

Questo problema si verificherà anche durante l’utilizzo di alcuni pacchetti come webpack-hot-middleware e l’apertura di più pagine contemporaneamente. webpack-hot-middleware creerà una connessione per ogni pagina per ascoltare le modifiche del codice, quindi per aggiornare la pagina. Ogni browser ha una limitazione di max-connections-per-server che è 6 per Chrome, quindi se hai già aperto più di 6 pagine in Chrome, la nuova richiesta verrà sospesa fino a quando non chiuderai alcune pagine.

Questo può anche accadere a causa di una nuova funzionalità chiamata isolamento del sito

Questa pagina descrive il problema e una soluzione . Che è quello di andare su chrome://flags/#site-isolation-trial-opt-out in chrome e cambiare l’impostazione in “Opt-out” e ricaricare chrome.

È un problema noto . Tuttavia quella pagina dice che è stato risolto in chrome 68, ma sto utilizzando Chrome 68 e ho ancora il problema.

Ciò potrebbe essere dovuto al fatto che hai inviato una richiesta Ajax, ma in questo momento puoi passare la tua pagina a un’altra utilizzando location.href o qualcosa del genere. Quindi la richiesta di anteprima è fallita.