Tipps und Tricks rund um .NET und Visual Studio

Tools Mit Fiddler sehen wie Browser und Server kommunizieren
Kommentare

Im heutigen Teil von .NETversum erklären Holger Schwichtenberg und Manfred Steyer wie man mit „Fiddler“ sehen kann, wie Browser und Server miteinander kommunizieren.

Fiddler (deutsch: Geiger) ist ein kostenfreier Netzwerkmonitor für den Datenverkehr zwischen Browser und einem Webserver. Dieses Werkzeug ist extrem hilfreich für alle Webentwickler, egal, ob sie rein serverseitig oder mit AJAX entwickeln. Fiddler übernimmt die Funktion eines Proxy-Servers, indem es sich beim Start als WinINET-Proxy registriert (vgl. SYSTEMSTEUERUNG | INTERNETOPTIONEN | VERBINDUNGEN | LAN-EINSTELLUNGEN | PROXYSERVER | ERWEITERT | PROXYEINSTELLUNGEN). Alle Browser, die sich um die WinINET-Proxy-Einstellung (nicht nur Internet Explorer, auch Chrome, Opera und Firefox!) kümmern, senden fortan die HTTP-Anfragen an Fiddler. Fiddler leitet die Anfrage dann an den eigentlichen Empfänger weiter. Im Fiddler-Fenster sieht man auf der linken Seite alle vom Browser ausgehenden HTTP-Anfragen mit Statuscode, Ziel, Größe und Dauer. Wie Abbildung 1 zeigt, führt der Aufruf von www.dotnet.de zu ganzen 120 (!) HTTP-Requests.

Abb. 1: Fiddler zeigt, was zwischen Browser und Webserver passiert, wenn man www.dotnet.de aufruft
Abb. 1: Fiddler zeigt, was zwischen Browser und Webserver passiert, wenn man www.dotnet.de aufruft

Bei Microsoft.de sind es 67. Bei Microsoft.com aber nur 34. In der rechten Fensterhälfte stehen verschiedene Werkzeuge (genannt „Inspectors“) zur Verfügung, um zu einem einzelnen Request die zugehörige Antwort zu betrachten. Für Textformate wie HTML und CSS gibt es die Ansichten Syntax View oder RAW. Auch Web-Service-Aufrufe (z. B. für Silverlight ist Fiddler sehr hilfreich, um zu beobachten, was zwischen Client und Server passiert) kann man hier betrachten. Im Fall einer binären Serialisierung sieht man aber erst einmal nicht so viel vom Nachrichteninhalt. Dafür gibt es ein Erweiterungsmodul: WCF Binary-encoded Message Inspector for Fiddler http://archive.msdn.microsoft.com/wcfbinaryinspector. Bilder schaut man sich im ImageView an. Der HTML Inspector deckt auf, wo Webseiten neben dem eigentlichen Seiteninhalt zu viel Overhead beinhalten (Abb. 2).

Abb. 2: Der HTML-Inspektor macht den Overhead durch den ViewState in ASP.NET deutlich (am Beispiel www.HolgerSchwichtenberg.de)
Abb. 2: Der HTML-Inspektor macht den Overhead durch den ViewState in ASP.NET deutlich (am Beispiel www.HolgerSchwichtenberg.de)

Das kann Fiddler noch:

  • SSL-Datenverkehr mitschneiden, indem man Fiddler als „Man in the Middle“ konfiguriert. Der Browser wird dann natürlich misstrauisch. Wenn man das Fiddler-Zertfikat auf dem eigenen Rechner installiert, entfallen aber die lästigen Browserwarnungen.
  • Der Nutzer kann die anzuzeigenden Anfragen filtern (z. B. nach URL, Inhaltstyp, Statuscode, Größe).
  • Man kann Haltepunkte definieren. Das sind Bedingungen, unter denen Fiddler die Kommunikation zwischen Browser und Webserver bis zum Eingriff des Benutzers anhält.
  • Fiddler kann komprimierten Datenverkehr (auf Wunsch automatisch) dekomprimieren.
  • Man kann einen HTTP-Request unverändert/verändert neu absetzen (Replay) oder komplett manuell konstruieren (Request Builder).
  • Fiddler kann mit vordefinierten statischen Antworten reagieren, statt den Webserver zu fragen (Autoresponder).
  • Fiddler kann sich gegenüber dem Webserver als ein anderer Browser ausgeben (Rules/User Agent).
  • Die HTTP-Anfragen können gespeichert und später wieder geladen werden.
  • Der Nutzer kann HTTP-Anfragen als .webtest-Datei für Visual Studio Webtests oder .wcat-Datei für das Microsoft Web Capability Analysis Tool exportieren.
  • Durch JScript.NET-Code kann man Fiddler erweitern. Auch mit anderen .NET-Sprachen kann man arbeiten, wobei .NET 2.0 die Obergrenze ist.

Noch ein wichtiger Tipp: Zu beachten ist, dass einige Anwendungen (darunter Internet Explorer und das .NET Framework) bei http://localhost und http://127.0.0.1 den WinINET-Proxy umgehen. In diesem Fall muss man die Adresse mit http://rechnername oder einem Punkt hinter „localhost“, also http://localhost. aufrufen, damit Fiddler den Datenverkehr mitbekommt. Bei einem Web Service muss man also in der Clientkonfiguration die Adresse ändern, z. B 

Dr. Holger Schwichtenberg (MVP) und FH-Prof. Manfred Steyer arbeiten bei www.IT-Visions.de als Softwarearchitekten, Berater und Trainer für .NET-Technologien. Dabei unterstützen Sie zahlreiche Unternehmen beim Einsatz von .NET und entwickeln selbst in größeren Projekten. Sie haben zahlreiche Fachbücher geschrieben und gehören seit vielen Jahren zu den Hauptsprechern auf der BASTA. Manfred Steyer ist zudem verantwortlich für den Fachbereich „Software Engineering“ der Studienrichtung „IT und Wirtschaftsinformatik“ an der FH CAMPUS 02 in Graz. Dr. Holger Schwichtenberg unterrichtet in Lehraufträgen an den Fachhochschulen Münster und Graz.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -