Chrome ora può inviare di nuovo qualsiasi richiesta. Che cosa ti dice e che cosa non ti dice

Le note di DevTools di Chrome 152 sono uscite il 25 agosto 2026, e una riga al loro interno conta più di quanto la sua lunghezza suggerisca. La vecchia voce di menu Replay XHR del pannello Network ora è semplicemente Resend, e la descrizione che Chrome dà del cambiamento è precisa:

Ora supporta tutte le richieste di rete recuperabili, convertendo le richieste standard in chiamate fetch() e preservando la piena fedeltà del replay accanto a XHR.

Replay XHR è rimasto in quel menu per anni, utile solo per il tipo specifico di richiesta che nominava. Qualsiasi altra richiesta fallita - l’invio di un modulo, il recupero di un documento, un caricamento - andava ricostruita a mano come comando curl o dentro un client. Ora ci fai clic destro sopra e la mandi di nuovo.

La stessa versione dà alla scheda Payload opzioni di decodifica - Base64, Hex e UTF-8 - per i corpi di richiesta binari e compressi, rispecchiando ciò che la scheda Response già offriva. Chi ha guardato un caricamento di file fallito o un corpo compresso senza vederci nulla di utile ora ha tre modi per leggerlo.

Perché conta quando la richiesta non era la tua

Entrambi i cambiamenti toccano la stessa attività: capire che cosa è successo partendo da una richiesta che non hai fatto tu.

Sono la maggior parte delle segnalazioni di bug. Qualcuno ha incontrato un errore, la richiesta fallita è davanti a te, e la domanda è se da lì riesci ad arrivare a una causa. Poterla inviare di nuovo con un clic, e leggere un corpo che prima era opaco, toglie due commissioni da quel lavoro.

La parte su cui vale la pena stare attenti

Un nuovo invio non è la richiesta che è fallita. È una richiesta nuova che le somiglia.

Parte dal tuo browser, con i tuoi cookie, la tua sessione, le tue estensioni e il tuo indirizzo IP, in un momento che non è quello in cui è fallita all’inizio. Sono quattro differenze prima ancora che tu abbia cambiato qualcosa, e ognuna di esse può ribaltare l’esito:

A che cosa risponde un nuovo invio

Questa forma di richiesta fallisce per me, da qui, adesso?

A che cosa deve rispondere la segnalazione

Perché questa richiesta è fallita per quella persona, sulla sua sessione, in quel momento?

Un 403 che rinviato torna 200 di solito significa che la differenza stava nella sessione e non nella richiesta. Un 500 che rinviato torna ancora 500 è un regalo, perché hai una riproduzione che controlli. Un timeout che rinviato risponde all’istante ti sta dicendo che lo stato che lo ha causato è passato, ed è esattamente il caso del 504.

Niente di tutto questo rende Resend meno utile. Ne fa una prima domanda invece che una risposta, e sapere quale delle due hai in mano è tutta l’abilità.

Che cosa deve portare la segnalazione perché tutto questo funzioni

Non puoi inviare di nuovo una richiesta che non hai. Ciò che rende questa nuova possibilità raggiungibile è se la richiesta fallita è sopravvissuta al viaggio dalla persona che l’ha vista a quella che la corregge, con il suo metodo, il suo URL, le sue intestazioni e il suo corpo intatti.

È a questo che serve un registro di rete in una segnalazione di bug, ed è per questo che i file HAR esistono come formato.

Un limite onesto dalla nostra parte: mascheriamo per impostazione predefinita le intestazioni e i valori delle credenziali, e su un dominio che non ha chiesto altro li mascheriamo ovunque. Quindi una richiesta rigiocata a partire da una segnalazione catturata da noi avrà di solito bisogno che l’autorizzazione la fornisca chi la sta rigiocando. È lo scambio che abbiamo scelto - una segnalazione è un link che qualcuno può aprire, quindi tutto ciò che viene catturato è di fatto condiviso - ed è bene saperlo prima di chiedersi perché il nuovo invio è tornato non autorizzato.

Il resto della versione, in breve

Altre tre cose nelle stesse note valgono il minuto di uno sviluppatore.

Copy as preload element. Fai clic destro su una richiesta e ottieni un tag <link rel="preload"> pronto da incollare, il che trasforma un’osservazione sulle prestazioni in una modifica senza il passaggio intermedio di cercare la sintassi.

L’esportazione strutturata delle tabelle nella console, così che una tabella che hai registrato possa uscire dalla console come dati e non come screenshot di dati.

Il passaggio tra l’albero del DOM e l’albero di accessibilità dal menu contestuale in Elements, con “scroll into view” per i nodi di accessibilità. Piccolo, e abbassa il costo di controllare la cosa che la maggior parte dei team controlla di meno.

Che cosa portarsi via

Una nota di rilascio di un browser di solito non merita una seconda lettura, e questa la merita, per un motivo che non ha nulla a che fare con la grandezza delle funzionalità: migliora gli strumenti attorno alle prove raccolte da qualcun altro. È una categoria in cui la maggior parte degli strumenti di debug è stata storicamente scarsa, perché danno per scontato che chi ha il browser davanti sia chi ha trovato il bug.

Di solito non sono la stessa persona. Tutto ciò che accorcia la distanza tra le due vale più di quanto la sua nota di rilascio suggerisca.

Le note di Chrome sono il posto dove leggere l’elenco completo: What’s new in DevTools (Chrome 152).