Chrome kann jetzt jede Anfrage erneut senden. Was Ihnen das sagt und was nicht

Die DevTools-Notizen zu Chrome 152 erschienen am 25. August 2026, und eine Zeile darin wiegt schwerer, als ihre Länge vermuten lässt. Der alte Menüpunkt Replay XHR im Network-Panel heißt jetzt schlicht Resend, und Chromes eigene Beschreibung der Änderung ist genau:

Es unterstützt jetzt alle abrufbaren Netzwerkanfragen und wandelt Standardanfragen in fetch()-Aufrufe um, wobei die volle Wiedergabetreue der Wiederholung neben XHR erhalten bleibt.

Replay XHR saß jahrelang in diesem Menü und war nur für die eine Art von Anfrage nützlich, die es benannte. Jede andere fehlgeschlagene Anfrage - ein Formularversand, ein Dokumentabruf, ein Upload - musste von Hand als curl-Befehl oder in einem Client nachgebaut werden. Jetzt klicken Sie mit der rechten Maustaste darauf und senden sie noch einmal.

Dieselbe Version gibt der Registerkarte Payload Dekodierungsoptionen - Base64, Hex und UTF-8 - für binäre und komprimierte Anfragekörper, und spiegelt damit, was die Registerkarte Response schon vorher bot. Wer je auf einen fehlgeschlagenen Datei-Upload oder einen komprimierten Body geschaut und nichts Brauchbares gesehen hat, hat nun drei Wege, ihn zu lesen.

Warum das zählt, wenn die Anfrage nicht Ihre war

Beide Änderungen betreffen dieselbe Tätigkeit: herauszufinden, was passiert ist, aus einer Anfrage, die Sie nicht selbst gestellt haben.

Das sind die meisten Fehlerberichte. Jemand ist auf einen Fehler gestoßen, die fehlgeschlagene Anfrage liegt vor Ihnen, und die Frage ist, ob Sie von ihr aus zu einer Ursache kommen. Sie mit einem Klick erneut senden zu können und einen Körper zu lesen, der früher undurchsichtig war, nimmt zwei Botengänge aus dieser Arbeit heraus.

Der Teil, bei dem Vorsicht angebracht ist

Ein erneutes Senden ist nicht die Anfrage, die fehlgeschlagen ist. Es ist eine neue Anfrage, die so aussieht wie sie.

Sie läuft aus Ihrem Browser, mit Ihren Cookies, Ihrer Sitzung, Ihren Erweiterungen und Ihrer IP-Adresse, zu einer Zeit, die nicht die Zeit des ursprünglichen Fehlschlags ist. Das sind vier Unterschiede, bevor Sie überhaupt etwas geändert haben, und jeder von ihnen kann das Ergebnis umkippen:

Was ein erneutes Senden beantwortet

Schlägt diese Form von Anfrage bei mir fehl, von hier aus, gerade jetzt?

Was der Bericht beantworten muss

Warum schlug diese Anfrage bei jener Person fehl, in ihrer Sitzung, in jenem Moment?

Ein 403, der erneut gesendet als 200 zurückkommt, heißt meist, dass der Unterschied in der Sitzung lag und nicht in der Anfrage. Ein 500, der erneut gesendet wieder ein 500 ist, ist ein Geschenk, denn Sie haben eine Reproduktion, die Sie kontrollieren. Ein Timeout, der erneut gesendet sofort antwortet, sagt Ihnen, dass der Zustand, der ihn verursacht hat, vorbei ist - genau der 504-Fall.

Nichts davon macht Resend weniger nützlich. Es macht daraus eine erste Frage statt einer Antwort, und zu wissen, welches von beiden Sie in der Hand halten, ist die ganze Kunst.

Was der Bericht tragen muss, damit irgendetwas davon funktioniert

Sie können eine Anfrage nicht erneut senden, die Sie nicht haben. Was diese neue Möglichkeit überhaupt erreichbar macht, ist die Frage, ob die fehlgeschlagene Anfrage den Weg von der Person, die sie gesehen hat, zu der Person, die sie behebt, überstanden hat, mit ihrer Methode, ihrer URL, ihren Headern und ihrem Body intakt.

Dafür ist ein Netzwerkprotokoll in einem Fehlerbericht da, und deshalb gibt es HAR-Dateien als Format überhaupt.

Eine ehrliche Grenze auf unserer Seite: Wir maskieren Header und Werte mit Anmeldedaten standardmäßig, und auf einer Domain, die nichts anderes verlangt hat, maskieren wir sie überall. Eine Anfrage, die aus einem von uns erfassten Bericht wiederholt wird, braucht ihre Autorisierung deshalb meist von der Person, die die Wiederholung durchführt. Diesen Kompromiss haben wir gewählt - ein Bericht ist ein Link, den jemand öffnen kann, also ist alles Erfasste faktisch geteilt - und es ist gut, das zu wissen, bevor Sie sich wundern, warum das erneute Senden unautorisiert zurückkam.

Der Rest der Version, kurz

Drei weitere Dinge in denselben Notizen sind die Minute eines Entwicklers wert.

Copy as preload element. Klicken Sie mit der rechten Maustaste auf eine Anfrage und Sie bekommen ein fertiges <link rel="preload">-Tag zum Einfügen, was eine Beobachtung zur Performance in eine Änderung verwandelt, ohne den Zwischenschritt, die Syntax nachzuschlagen.

Strukturierter Tabellenexport in der Konsole, damit eine Tabelle, die Sie geloggt haben, die Konsole als Daten verlassen kann und nicht als Screenshot von Daten.

Umschalten zwischen DOM-Baum und Accessibility-Baum über das Kontextmenü in Elements, mit “scroll into view” für Accessibility-Knoten. Klein, und es senkt die Kosten dafür, das zu prüfen, was die meisten Teams am seltensten prüfen.

Was daraus mitzunehmen ist

Eine Release-Notiz zu einem Browser ist selten ein zweites Lesen wert, und diese ist es, aus einem Grund, der nichts damit zu tun hat, dass die Funktionen groß wären: Sie verbessert das Werkzeug rund um Belege, die jemand anderes gesammelt hat. Das ist eine Kategorie, in der die meisten Debugging-Werkzeuge historisch schlecht waren, weil sie annehmen, dass die Person am Browser die Person ist, die den Fehler gefunden hat.

Das sind meist nicht dieselben Personen. Alles, was den Abstand zwischen beiden verkürzt, ist mehr wert, als seine Release-Notiz vermuten lässt.

Chromes eigene Notizen sind der Ort für die vollständige Liste: What’s new in DevTools (Chrome 152).