Jemand bittet Sie um eine HAR-Datei. Meistens ist es der Support oder ein Entwickler, der sich einen von Ihnen gemeldeten Fehler ansieht, und meistens kommt die Bitte mit einer Anleitung, die voraussetzt, dass Sie längst wissen, was das ist.

Eine HAR-Datei ist eine Aufzeichnung jeder Anfrage, die der Browser gestellt hat, während Sie etwas getan haben, gespeichert als eine einzige Datei. HAR steht für HTTP Archive. Es ist eine schlichte JSON-Datei, die jede Anfrage der Seite auflistet, was zurückkam, wie lange jede gedauert hat und in welcher Reihenfolge - der Netzwerk-Tab der Entwicklertools Ihres Browsers, aufgeschrieben und weitergegeben.

Was darin steht

Für jede Anfrage, die die Seite während der Aufnahme gestellt hat:

  • Die Anfrage: Methode, vollständige URL, Header, Query-String und der Body, falls es einen gab
  • Die Antwort: Statuscode, Header, Content-Type, Größe und oft der Body
  • Zeiten: wie lange die Anfrage gewartet, verbunden, gesendet und auf das erste Byte gewartet hat
  • Wann es passiert ist, sodass die Reihenfolge und die Abstände zwischen den Anfragen erhalten bleiben

Der letzte Punkt ist es, der eine HAR-Datei nützlicher macht als einen Screenshot des Netzwerk-Tabs. Ein Screenshot zeigt Ihnen eine Liste; eine HAR-Datei lässt jemanden die Abfolge nachspielen und sehen, dass die Token-Erneuerung erst nach der Anfrage lief, die sie gebraucht hätte.

Wann jemand danach fragt

Fast immer, weil ein Problem von außen unsichtbar ist und nur bei Ihnen auftritt.

  • Eine Seite lädt bei Ihnen und bei den anderen nicht, oder umgekehrt
  • Etwas scheitert stillschweigend, ohne dass die Oberfläche etwas davon sagt
  • Eine Anfrage ist langsam, und niemand kann sagen, ob es am Netz, am Server oder am Browser liegt
  • Eine Integration liefert einen Fehler nur in der Produktion, nur für ein Konto

In all diesen Fällen ist die Antwort meist eine Zeile in einer Datei, die sich niemand angesehen hat: ein 403, wo ein 200 erwartet wurde, eine Anfrage, die nie losging, eine Weiterleitungsschleife, ein CORS-Fehler, den die Seite verschluckt hat.

Wie man eine aufzeichnet

Chrome oder Edge. Öffnen Sie die Entwicklertools mit F12 oder Cmd + Option + I auf einem Mac. Gehen Sie auf den Tab Netzwerk. Setzen Sie den Haken bei Protokoll beibehalten, damit eine Weiterleitung nicht löscht, was Sie aufgezeichnet haben. Reproduzieren Sie das Problem. Klicken Sie dann mit der rechten Maustaste auf eine beliebige Zeile in der Liste und wählen Sie Alle als HAR mit Inhalt speichern.

Firefox. Entwicklertools, Tab Netzwerkanalyse, reproduzieren, dann Rechtsklick auf eine Zeile und Alles als HAR speichern wählen.

Safari. Aktivieren Sie das Menü “Entwickeln” in den Einstellungen, dann Entwickeln, Webinspektor einblenden, Netzwerk und Exportieren.

Zwei Dinge werden dabei übersehen. Beginnen Sie die Aufnahme, bevor Sie vorführen, worum es geht, denn der Netzwerk-Tab hält nur fest, was er gesehen hat. Und reproduzieren Sie das Problem einmal und hören Sie dann auf: eine HAR-Datei mit elf Minuten Herumklicken ist eine Datei, die niemand liest.

Eine lesen, ohne ein Werkzeug dafür

Der schnellste Einstieg ist, die Datei im Netzwerk-Tab eines Browsers zu öffnen: ziehen Sie die HAR-Datei auf das Netzwerk-Panel, und sie lädt, als hätten Sie sie selbst aufgezeichnet, sortierbar und filterbar.

Worauf zu achten ist, ungefähr in dieser Reihenfolge:

Nicht als Erstes
Die ganze Liste durchscrollen und nach etwas suchen, das falsch aussieht
Zuerst dies
Auf Status 400 und höher filtern, dann auf die langsamsten Anfragen, dann ansehen, was unmittelbar vor dem Fehlschlag passiert ist

Eine HAR-Datei ist JSON, also arbeitet auch jq damit: jq '.log.entries[] | select(.response.status >= 400) | {url: .request.url, status: .response.status}' capture.har holt Ihnen die Fehlschläge in einer Zeile heraus.

Eine HAR-Datei hält nur Anfragen fest, die der Browser gestellt hat. Um eine zu untersuchen, die Ihr eigener Code sendet, richten Sie ihn auf den Webhook-Testendpunkt, der Ihnen eine URL gibt und Methode, Header, Query-String und Body von allem zeigt, was dort ankommt.

Der Teil, vor dem niemand warnt

Eine HAR-Datei enthält in aller Regel Zugangsdaten. Das ist das Wichtigste, was man über sie wissen muss, und die Anleitungen, die einem geschickt werden, erwähnen es selten.

Mit Inhalt gespeichert, enthält eine HAR-Datei jeden Request-Header, also Session-Cookies und Autorisierungs-Token, und jeden Response-Body, in dem personenbezogene Daten der angemeldeten Person stehen können. Wer die Datei hat, kann oft als dieser Benutzer handeln, bis diese Token ablaufen.

Also:

  • Behandeln Sie eine HAR-Datei wie ein Passwort. Fügen Sie keine in einen öffentlichen Issue-Tracker ein, in einen geteilten Kanal oder in einen E-Mail-Verlauf, der weitergeleitet wird.
  • Bereinigen Sie sie vor dem Weitergeben, wenn Sie können. Manche Werkzeuge entfernen Cookies und Autorisierungs-Header; sonst öffnen Sie das JSON und löschen sie von Hand.
  • Zeichnen Sie in einem privaten Fenster mit einem Testkonto auf, wo das Problem es zulässt; dann bleiben echte Kundendaten ganz aus der Datei heraus.
  • Löschen Sie sie danach. Sie ist ein Beleg für eine Untersuchung, kein Dokument.

Wenn Sie derjenige sind, der um eine HAR-Datei bittet, schreiben Sie all das in die Bitte. Den meisten, die Ihnen eine mit ihrem gültigen Session-Token schicken, hat nie jemand gesagt, dass sie es nicht tun sollen.

Eine bekommen, ohne die Anleitung

Alles oben sind vier Absätze Anleitung für jemanden, der nur melden möchte, dass eine Seite kaputt ist - und genau deshalb kommen HAR-Dateien so oft gar nicht erst an.

Session Replay

Kostenlose Chrome-Erweiterung. Ein Klick auf der Seite, die sich falsch verhält, erfasst den Screenshot, die Konsole und das Netzwerkprotokoll und gibt Ihnen einen Link, den Sie ins Ticket einfügen können.

Erweiterung holen

Das Netzwerkprotokoll, das sie aufnimmt, enthält eine HAR-Datei, die Sie herunterladen und in den Entwicklertools öffnen können - wer den Bericht aufnimmt, bekommt also dieselbe Datei, um die er sonst hätte bitten müssen. Was sie nicht tut, ist für Sie zu entscheiden, was zu schwärzen ist: die Warnung oben gilt weiterhin für alles, was Sie weitergeben.

Für alles, was um die Datei herum gehört - was Sie erwartet haben, was passiert ist und welcher Build es war - hat der Leitfaden für Fehlerberichte die Vorlage.