Cosa succede quando passo con il mouse su un collegamento in Chrome?

Quando si http://a//%%30%30fa clic su questo collegamento ( ) in Google Chrome, Chrome si interrompe e chiude tutte le schede e le istanze.

Ma, in alcuni casi, ho solo bisogno di passare il mouse sopra il collegamento e la scheda si arresta in modo anomalo.

Cosa succede quando passo con il mouse su questo link? Voglio dire, cosa fa Chrome quando passa il mouse sopra un link?

L'arresto anomalo è dovuto a un bug scoperto di recente in Chrome - e in altri browser WebKit (!) * - specificamente correlato a %%30%30, %0%30o %%300come parte dell'URL, che internamente finisce per rappresentare lo stesso simbolo: null . Puoi leggere di più sul bug qui .

Non è un bug che interessa la maggior parte dei collegamenti, quindi in genere non devi preoccuparti di passare il mouse sopra i collegamenti.

Note:
* Altri browser WebKit includono Safari, Opera, Steam Browser, Midori, S60 (Symbian), Blackberry Browser e Playstation 3, ma non Firefox, Internet Explorer o Edge.

Modifica: questo bug è stato risolto in Chrome 45.0.2454.101 come sottolinea Deltik .

Maggiori informazioni su cosa succede

Il problema è correlato al canonicalizer dell'URL , che viene eseguito non appena si passa con il mouse su un collegamento, probabilmente per visualizzare il collegamento nella barra di stato del browser e per precaricare la pagina Web in modo che si carichi più velocemente dopo aver fatto clic.

Per quanto riguarda il ruolo del canonicalizer dell'URL:
quando un URL è scritto HTML, può essere scritto in una forma come /homeo ../../home, ma i browser devono tradurre questo URL in qualcosa con un protocollo e anche un dominio, come http://superuser.com/home. Inoltre, l'URL può contenere URL Escapes che devono essere tradotti e questi escape sono codificati in percentuale , come %%30%30. (Un elenco più esaustivo di URL fuoriesce qui ).
La funzionalità che gestisce questa traduzione di URL è ciò che sta per finire in crash, perché riceve input che gli sviluppatori non si aspettavano / gestiscono.

Ecco un riepilogo della modifica del codice che ha risolto il problema:

Gestire correttamente le fughe nidificate problematiche nei percorsi URL.

In particolare, se l'escaping nell'input porta all'URL di output contenente una nuova sequenza di escape, ad esempio convertendo l'input "%% 30% 30" in "% 00", evita il principale "%" come "% 25" per garantire l'output la sequenza non viene considerata come una nuova sequenza di escape valida.

Ciò garantisce che la canonicalizzazione dello stesso URL una seconda volta non apporti modifiche ad esso, il che è importante per evitare arresti anomali e altri bug in una varietà di posizioni sia in build di debug che di versioni.

Come dice Fabio Turati,

Quando passi con il mouse sopra un link, Chrome lo visualizza nell'angolo in basso a sinistra. Ciò richiede una certa elaborazione, inclusa la "traduzione" di caratteri appositamente codificati.

Tuttavia, dal tuo post e commento penso che tu sia più preoccupato se Chrome si collega al link in background. Lo fa , così come altri browser moderni ( Firefox , Opera ). Potresti voler disabilitare il prefetch nelle preferenze di Chrome o installare uBlock Origin per ottenere più impostazioni sulla privacy.

Volevo dare ulteriori chiarimenti su cosa succede esattamente qui.

Fondamentalmente,% 30 è uno 0 con codifica URL e% 00 è un NULL con codifica URL (che viene visualizzato in binario come 0000 0000). Pertanto, se si dispone di un URL con un carattere codificato nidificato che verrà decodificato in NULL, il bug si verifica.

Chrome esegue le seguenti operazioni canonicalizzando un URL (fonte: https://code.google.com/p/chromium/issues/detail?id=533361#c13 ):

• Una stringa di input "http: //a.com/%%30%30" non è convertita in " http://a.com/%00 " e considerata una GURL valida.
• Questo GURL viene infine inviato a GURLToDatabaseURL (), che chiama ReplaceComponents () su di esso per rimuovere nome utente e password.
• ReplaceComponents () canonicalizza nuovamente l'URL.
• La canonicalizzazione del percorso colpisce la sequenza "% 00", annulla l'escaping, vede questo è un carattere 0 che non è valido negli URL, lo lascia scappare, ma contrassegna l'URL risultante come non valido.
• Una volta tornato a GURLToDatabaseURL (), chiama .spec () sul nuovo URL, aspettandosi che sia valido, poiché l'URL di input era garantito e abbiamo semplicemente rimosso il nome utente e la password. Questo DCHECKs.

Quindi l'URL viene dapprima considerato valido, ma dopo aver rimosso alcuni dati privati, viene invalidato. Tuttavia, dopo che tali dati sono stati rimossi, la funzione che ha chiamato quel particolare codice prevede un URL valido.

Parte del motivo per cui questo URL è considerato non valido è perché NULL viene utilizzato in un numero di software e linguaggi più vecchi per indicare la fine di una stringa (poiché sono sostanzialmente 8 zero in una riga, che è facile da rilevare per un computer).