"ATTENZIONE: vengono visualizzate le intestazioni provvisorie" nel debugger di Chrome

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

Vengono visualizzate le intestazioni provvisorie di attenzione

Ho trovato qualcosa di forse pertinente, Network Panel: aggiungere cautela riguardo alle intestazioni di richieste provvisorie , ma non sono riuscito a capirlo appieno. È possibile trovare domande correlate e non è possibile caricare richieste di blocchi di Chrome e XMLHttpRequest. Le risorse scaricate mostrano attenzione: vengono visualizzate 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 aggiustare 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 vi è alcuna risposta se la richiesta è stata bloccata.

Il modo in cui ho scoperto l'estensione che stava bloccando la mia risorsa è stato tramite lo strumento net-internals in Chrome:

Per le ultime versioni di Chrome

• Digita chrome://net-export/la barra degli indirizzi e premi invio.
• Inizia a registrare. E salva il file di registrazione in locale.
• Apri la pagina che mostra problemi.
• Torna a net-internals
• È possibile visualizzare il file di registro registrato qui https://netlog-viewer.appspot.com/#import
• 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 vedi se le informazioni visualizzate ti dicono qualcosa.

Per versioni precedenti di cromo

• Digita chrome://net-internalsla barra degli indirizzi e premi invio.
• Apri la pagina che mostra problemi.
• Torna a net-internals, fai clic su 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 vedi se le informazioni visualizzate ti dicono qualcosa.

Credo che accada quando la richiesta effettiva non viene inviata. Di solito si verifica quando si carica una risorsa memorizzata nella cache.

Per Chrome v72 + ciò che ha risolto per me è stato solo questo:

vai a chrome://flags/e disabilita questi 3 flag

• Disabilita l'isolamento del sito
• Abilita servizio di rete
• Esegue il servizio di rete in-process

oppure puoi farlo dalla riga di comando:

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

perché questo accada?

Sembra che Google stia eseguendo il refactoring del proprio motore Chromium in una struttura modulare, in cui servizi diversi verranno suddivisi in moduli e processi autonomi. Chiamano questo processo di servizio. Il servizio di rete è il primo passo, stanno arrivando il servizio Ui, il servizio di identità e il servizio dispositivo. Google fornisce le informazioni ufficiali sul sito del progetto Chromium .

è pericoloso cambiarlo?

Un esempio è il networking: una volta che abbiamo un servizio di rete, possiamo scegliere di esaurirlo per una migliore stabilità / sicurezza o in-process se siamo a corto di risorse . fonte

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 angolare e un nodo back-end su SSL e l'API si trova su un dominio diverso in esecuzione sulla porta 8081, quindi sto facendo richieste CORS e conCredentials mentre sto rilasciando un cookie di sessione dall'API

Quindi, nello specifico, il mio scenario era: la richiesta POST, conCredentials alla porta 8081, ha causato il messaggio "ATTENZIONE: sono mostrate le intestazioni provvisorie" nell'ispettore e ovviamente ha bloccato la richiesta tutti insieme.

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

Questo può accadere anche (solo per richieste di origine incrociata) a causa di una nuova funzione chiamata isolamento del sito

Questa pagina illustra in dettaglio il problema e una soluzione . Quale è andare achrome://flags/#site-isolation-trial-opt-out in Chrome e cambiare l'impostazione su "Disattiva" e ricaricare Chrome.

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

Le risorseProvisional headers are shown Push HTTP / 2 produrranno nell'ispettore la stessa teoria di @wvega pubblicata nella sua risposta sopra .

ad es .: poiché il server ha trasferito le risorse al client ( prima che il client le richiedesse ), il browser ha le risorse memorizzate nella cache e quindi il client non effettua / ha mai bisogno di richieste; Così perchè...

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

La mia situazione è legata all'origine incrociata .
Situazione: il browser invia la OPTIONSrichiesta prima di inviare la richiesta reale come GETo POST. Lo sviluppatore back-end si dimentica di gestire la OPTIONSrichiesta, lasciandola passare attraverso il codice del servizio, rendendo il tempo di elaborazione troppo lungo. Più lungo dell'impostazione di timeout che ho scritto axiosnell'inizializzazione, ovvero 5000 millisecondi. Pertanto, non è stato possibile inviare la richiesta reale e quindi ho riscontrato il provisional headers are shownproblema.
Soluzione: quando si tratta di OPTIONSrichiedere, il back-end API restituisce solo il risultato, rende la richiesta più veloce e la richiesta reale può essere inviata prima del timeout.

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

Si è scoperto che avevo un refuso nell'attributo href del tag A che stavo usando per sparare il post. Avevo digitato href = " javacsript:; " (invertendo la 's' e la 'c') .. questo ha fatto sì che lo script provasse ad aggiornare la pagina mentre il post stava tentando di sparare. ho corretto l'errore di battitura e ha funzionato perfettamente per me.

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

Ciò potrebbe essere dovuto al fatto che hai inviato una richiesta Ajax, ma allo stesso tempo salti la tua pagina su un'altra usando location.href o qualcosa del genere. Quindi la richiesta precedente non è riuscita.

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

Nel mio caso la richiesta è stata inviata correttamente al server, il codice sul lato server ha quindi generato un errore e la mia gestione personalizzata dell'errore 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.

Ho riscontrato questo problema con una chiamata AJAX che non sarebbe mai stata completata. Ho seguito i consigli e i suggerimenti di wvega sul debug con chrome://net-internalsper determinare eventualmente un altro clickgestore di eventi nella pagina, l'ascolto su un nodo principale, stava facendo sì che il browser passasse allo stesso URL (quindi non era facilmente evidente).

La soluzione era quella di aggiungere event.stopPropagation()un clickgestore sul pulsante di invio del modulo per evitare che il clic facesse il gorgoglio del DOM e annullasse la richiesta AJAX in corso (avviata tramite un submitgestore sul form).

Ho avuto questo risultato molto recentemente (oggi in effetti) in cui ho ricevuto una chiamata AJAX sul server e Chrome ha lanciato "Attenzione: vengono mostrate le intestazioni provvisorie". Nello scripting PHP lato server, ci sono query MySQL che possono essere praticamente istantanee o richiedere alcuni secondi a seconda dello scenario indicato. La risposta del mio server non viene rinviata al browser fino al completamento delle query. Ho scoperto che ricevo questo errore solo quando vengono eseguite query che richiedono molto tempo (fino a pochi secondi in totale) e impediscono che la risposta venga rispedita.

Il mio scenario prevede la rarissima possibilità di dover modificare una tabella aggiungendo / rimuovendo centinaia di colonne per l'output del modello meteorologico ... da qui il ritardo di risposta dall'iterazione attraverso un ciclo di query ALTER TABLE.

Un motivo comune ciò accade se si sta monitorando un evento e non si impedisce l'azione predefinita. Ad esempio, se hai un evento click, allora vorrai includere:

e.preventDefault();

o

return false;

In caso contrario, vedrai l'avvertenza delle intestazioni provvisorie e lo stato "annullato" nella scheda Rete della tua console web.

Nel mio caso era solo un percorso set falso in una risorsa (svg / img)

Questo problema si è verificato durante l'invio di un'intestazione di autorizzazione HTTP non valida. Ho dimenticato di codificarlo in base64.

Mi sono imbattuto in questo ed è andato via quando sono passato da https a http. I certificati SSL che utilizziamo in sviluppo non sono verificati da terzi. Sono solo certificati generati localmente.

Le stesse chiamate funzionano bene su Chrome Canary e Firefox. Questi browser non sembrano essere così severi riguardo al certificato SSL come Chrome. Le chiamate non riuscirebbero in Chrome con il messaggio "ATTENZIONE: intestazioni provvisorie ...".

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

Sto solo gettando i miei due centesimi. Sto scrivendo un'applicazione Web utilizzando le richieste CORS e un servizio Web completo RESTful. Ho scoperto che Chrome genererà questo errore quando viene generata un'eccezione non gestita o viene generato un errore PHP. Nel caso in cui qualcun altro incontri il problema. Ho scoperto che quando ciò accade, posso avviare l'app di Chrome "Postman - Rest Client" ed eseguire esattamente la stessa richiesta ma nell'app di Chrome riceverò effettivamente l'errore PHP che viene generato invece di questo errore non descrittivo.

Ho riscontrato questo problema quando ho provato a caricare main.js per richiedere js per la seconda volta dopo aver apportato modifiche a causa di un errore. Ho appena attivato Impostazioni degli strumenti di sviluppo "Disabilita cache (quando DevTools è aperto)". e quello ha fatto il fascino.

Un altro possibile scenario che ho visto: la stessa richiesta esatta viene inviata di nuovo subito dopo pochi millisecondi (molto probabilmente a causa di un bug sul lato client).
In tal caso, vedrai anche che lo stato della prima richiesta è "annullato" e che la latenza è solo di diversi millisecondi.

Questo stava accadendo per me, quando avevo un link per il download e dopo aver fatto clic su di esso stavo anche cercando di catturare il clic con jquery e inviare una richiesta Ajax. Il problema era perché quando si fa clic sul collegamento per il download, si esce dalla pagina, anche se non sembra così. Se non ci fosse alcun 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 era mostrata e stava ancora aspettando la mia accettazione o annullamento della stampa nel popup mentre nella pagina principale era anche in attesa in background che mostrava il messaggio ATTENZIONE sono mostrate le intestazioni provvisorie quando ho provato a fare clic su un altro collegamento.

Nel mio caso, la soluzione era rimuovere lo window.print ();script che stava eseguendo nella <body>finestra popup per impedire la finestra di dialogo di stampa.

Ho visto ciò accadere quando il numero di connessioni al mio server ha superato il limite massimo di 6 connessioni per server di Chrome.

Usa questo pugno di codice del tuo codice:

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

Questo funziona per me.

Ecco un'altra soluzione.

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

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

Se stai sviluppando un'applicazione Asp.Net Mvc e stai provando a restituire una JsonResultnel tuo controller, assicurati di aggiungere JsonRequestBehavior.AllowGetal Jsonmetodo. Ciò ha risolto il problema per me.

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

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

Il messaggio "Attenzione: vengono visualizzate le intestazioni provvisorie" può essere visualizzato quando il sito Web ospitato su HTTPS richiama una chiamata a WebApi ospitato su HTTP. Puoi controllare tutto se tutti i tuoi Api sono HTTPS. Il browser impedisce di effettuare una chiamata per risorse non sicure. Puoi vedere un messaggio simile nel tuo codice quando usi l'API FETCH per il dominio con HTTP.

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

Ho avuto un problema simile con la mia app MEAN. Nel mio caso, il problema si stava verificando in una sola richiesta get. Ho provato a rimuovere adblock, ho provato a cancellare la cache e ho provato con diversi browser. Niente ha aiutato.

infine, ho capito che l'API stava cercando di restituire un enorme oggetto JSON. Quando ho provato a inviare un piccolo oggetto, funzionava bene. Infine, ho modificato la mia implementazione per restituire un buffer anziché un JSON.

Vorrei che expressJS lanciasse un errore in questo caso.

Questo problema si verifica anche durante l'utilizzo di alcuni pacchetti simili webpack-hot-middlewaree l'apertura di più pagine contemporaneamente. webpack-hot-middlewarecreerà una connessione per ogni pagina per ascoltare le modifiche del codice, quindi per aggiornare la pagina. Ogni browser ha un max-connections-per-serverlimite di 6 per Chrome, quindi se hai già aperto più di 6 pagine in Chrome, la nuova richiesta verrà sospesa lì fino a quando non chiudi alcune pagine.

Nel mio caso la causa era l'estensione di AdBlock.

La richiesta al server è andata a buon fine e ho ricevuto la risposta ma non sono riuscito a vedere i cookie di richiesta a causa di "Intestazioni provvisorie ..." mostrate negli strumenti Dev. Dopo aver disabilitato AdBlock per il sito, l'avviso è scomparso e gli strumenti di sviluppo hanno iniziato a mostrare nuovamente i cookie.

Per rendere effettiva la modifica, era anche necessario chiudere gli strumenti Dev e aggiornare la pagina