Cosa fare con chrome inviando richieste extra?

Google Chrome invia più richieste per recuperare una pagina, e questo -apparentemente- non è un bug, ma una funzionalità. E noi, come sviluppatori, dobbiamo solo occuparcene.

Per quanto ho potuto scavare in cinque minuti, Chrome lo fa solo per rendere più veloce la navigazione, quindi se una connessione viene persa, la seconda prenderà il sopravvento.

Immagino che se il sito web è ben sviluppato, allora la funzionalità non si romperà di questo, perché più richieste non sono solo nuove.

Ma non sono sicuro di aver tenuto conto di tutte le situazioni che questa caratteristica può produrre.

Ci sarebbero situazioni speciali? Qualche buona pratica per trattare con loro?

Aggiornamento 1: ora capisco perché la pagina della mia banca genera un errore quando apro la pagina con Chrome! Dice: “Dovrebbe essere aperta solo una finestra del browser.” Questa è la loro soluzione alle minacce alla sicurezza? !!

La soluzione migliore è seguire le best practice di sviluppo Web standard: non modificare lo stato dell’applicazione come risultato di una chiamata GET.

Se sei preoccupato, ti consiglio di aggiornare i test dell’unità strato dati affinché le chiamate GET siano duplicate e assicurati che restituiscano gli stessi dati.

(Non vedo questo comportamento con Chrome 8.0.552.224, a proposito, è molto nuovo?)

Ho visto il comportamento sobject mentre scrivevo la mia applicazione server e ho scoperto che probabilmente le risposte precedenti non erano vere.

Chrome distribuisce una singola richiesta in più http per recuperare risorse in parallelo. In questo caso, è un’immagine che recupera come un get http separato.

Ho allegato una schermata di cattura dei pacchetti tramite wireshark.

È per una semplice richiesta di ottenere la porta 8080 per cui il mio server restituisce un messaggio di saluto.

Chrome invia la seconda richiesta di ottenere l’icona preferita che vedi in cima a ogni scheda aperta . NON è un secondo arrivare a soddisfare il time out o qualsiasi cosa del genere.

Dovrebbe essere considerato un altro elemento che differisce tra i vari browser.

Ecco una domanda di riferimento che ho trovato quest’ultimo

Chrome invia due richieste SO

chrome richiede l'icona preferita

Problema di Chrome su google code

Questo comportamento può essere causato da SRC = ” o SRC = ‘#’ in IMG o (come nel mio caso) tag IFRAME. La sostituzione di “#” con “about: blank” ha risolto il problema.

Qui http://forums.mozillazine.org/viewtopic.php?f=7&t=1816755 dicono che anche i tag SCRIPT possono essere il problema.

Questo succede solo quando abilito l’estensione “webug” (che è una sostituzione di FirePHP per Chrome). Se disattivo l’estensione, il server riceve solo una richiesta.

Può anche essere causato da tag di link con attributi href vuoti, almeno in Chromium (v41). Ad esempio, ognuna delle seguenti righe genererà una query aggiuntiva sulla pagina:

    

Sembra che cercare attributi vuoti nella pagina sia un buon punto di partenza, sia href che src .

La mia osservazione di questa caratteristica (bug / funzionalità / qualunque cosa) si verifica quando sto digitando un URL e il completamento automatico finisce su una corrispondenza mentre sto ancora digitando l’URL. Chrome prende quella corrispondenza e recupera la pagina, presumo per i vantaggi di memorizzazione nella cache che si verificano quando si carica la pagina da soli ….

Ho appena implementato un token guida monouso (asp.net/TSQL) che viene generato quando viene generata la prima forma in una serie di due (+ pagina di conferma). Il token è registrato come “in sospeso” nel DB quando viene generato. Il token di guida accompagna i post come campo nascosto e viene infine contrassegnato come chiuso quando l’operazione dell’utente viene completata (pagamento). Questo meccanismo funziona e impedisce a tutti i moduli di essere reinviati dopo aver effettuato il pagamento. Tuttavia, vedo 2 o 3 (!?) Token aggiuntivi generati da richieste aggiuntive rapidamente uno dopo l’altro. La prima richiesta è ciò che finisce davanti all’utente (localhost – so ie., Me), dove il contenuto generato finisce per le altre due richieste non ne ho idea. Inizialmente mi chiedevo perché i gestori di Page_Load sparassero più volte per un’impressione di una pagina, quindi ho provato una bandiera in Http.Context.Current, ma ho scoperto con mio disappunto che le richieste successive arrivano sullo stesso URL ma senza dati post, e empty Http.Context.Current array – ie., completamente (per scopi pratici) richieste http separate. Come gestirlo? Una sorta di token e logica per rifiutare le richieste di contenuto del corpo della pagina successive mentre il primo è ancora in fase di elaborazione? Immagino che questo potrebbe avvenire come un contesto globale?

Stavo avendo questo problema, ma nessuna delle soluzioni qui era il problema. Per me, è stato causato dall’estensione APNG in Chrome (supporto per PNG animati). Una volta disabilitata quell’estensione, non ho più visto doppie richieste di immagini nel browser. Devo notare che, indipendentemente dal fatto che la pagina stia emettendo un’immagine PNG, la distriggerszione di questa estensione ha risolto il problema (ad esempio, APNG sembra causare il problema per le immagini indipendentemente dal tipo di immagine, non devono essere PNG).

Ho avuto anche molte altre estensioni (come “Web Developer” che molti hanno suggerito è il problema), e quelli non erano il problema. Disabilitarli non ha risolto il problema. Sono anche in esecuzione in modalità sviluppatore e questo non ha fatto alcuna differenza per me.

Sto avendo lo stesso bug. E come la risposta precedente, questo problema è dovuto al fatto che ho installato l’ estensione chrome Validator Una volta disabilitata l’estensione, funziona normalmente.

Nel mio caso, ho dati di enpoint (json) su un server diverso e il browser effettua prima una richiesta vuota (Metodo di richiesta: OPZIONI) per verificare se un endpoint accetta richieste dal mio server, Stessa politica di origine. Anche goot per sapere è un’app Angular 1. In conclusione, faccio richieste da localhost a dati falsi online di JSON.

Nel mio caso, è stato Chrome (v65) a creare un secondo GET /favicon.ico , anche se la risposta era text/plain quindi chiaramente no in là che rimanda all'icona. Ha smesso di farlo dopo aver risposto con un 404.

Firefox (v59) inviava 2 richieste di favicon ; di nuovo ha smesso di farlo dopo il 404.