Fehlerfälle mit einem Debugging-Proxy entwerfen
Wählen Sie HTTP-Änderungen, Verzögerungen und abgebrochene Austausche passend zum Clientverhalten, das ein proxybasierter Test prüfen soll.
Ein Debugging-Proxy ist nützlich, wenn ein Client auf eine Antwort treffen soll, die der normale Server selten erzeugt. Definieren Sie zuerst das Clientverhalten und wählen Sie dann den Eingriff, der diesen Zustand herbeiführt.
„Die Anfrage ist fehlgeschlagen“ ist ein zu weiter Testfall. Eine gültige HTTP-Fehlerantwort, eine Antwort, die nie ankommt, und eine mitten im Download unterbrochene Verbindung verlangen dem Programm Unterschiedliches ab.
| Fall | Zu prüfendes Verhalten |
|---|---|
| Eine vollständige HTTP-Fehlerantwort | Ob der Client den Status liest und die vorgesehene Fehlerrichtlinie anwendet |
| Eine verzögerte Antwort | Ob der Nutzer abbrechen kann und ob das Zeitlimit in der vorgesehenen Phase greift |
| Ein unerwartetes Header- oder Body-Feld | Ob Parsen und Validierung deutlich fehlschlagen |
| Ein abgebrochener Austausch | Ob unvollständige Daten von einem fertigen Ergebnis unterscheidbar bleiben |
Eingriff auf der richtigen Ebene wählen
Charles bietet Breakpoints, die eine Anfrage oder Antwort vor dem Weiterleiten anhalten. Die abgefangene Nachricht lässt sich prüfen und bearbeiten, durchlassen oder abbrechen. Das Rewrite-Werkzeug wendet wiederholbare Änderungen auf passende Header, URLs oder Bodies an. Drosselung steuert Bandbreite und zusätzliche Latenz.
Diese Steuerungen können das Verhalten eines HTTP-Clients prüfen, doch eine Bandbreitengrenze ist kein genaues Modell für zufälligen IP-Paketverlust. Ein Proxy kann Daten puffern, Verbindungen wiederverwenden und eine eigene Upstream-Verbindung öffnen. Wählen Sie ein Werkzeug zur Netzwerkbeeinträchtigung, wenn der benötigte Zustand ausdrücklich unterhalb von HTTP liegt.
Jeden Fall interpretierbar halten
Treffen Sie Host und Pfad eng. Beginnen Sie mit einem normalen Austausch, aktivieren Sie eine Änderung und protokollieren Sie, was geändert wurde. Erreicht ein Wiederholungsversuch einen zweiten Endpunkt, entscheiden Sie, ob dieselbe Regel auch diesen Versuch betreffen soll. Ein unbedingtes Rewrite kann sonst jeden Wiederherstellungspfad in den ursprünglichen Fehler verwandeln.
Bei einem Upload oder einer zahlungsähnlichen Operation beweist eine verlorene Antwort nicht, dass der Server die Anfrage abgelehnt hat. Nehmen Sie diese Mehrdeutigkeit in den Wiederholungsfall auf, statt zu behaupten, jeder Transportfehler sei gefahrlos wiederholbar.
Das Prüfen oder Bearbeiten von HTTPS-Inhalten setzt voraus, dass der Client an der TLS-Inspektion des Debugging-Proxys teilnimmt. Ein Proxy, der nur CONNECT weiterleitet, sieht verschlüsselte Anwendungsbytes. Verwenden Sie eine isolierte Testkonfiguration und stellen Sie danach Routing und Vertrauenseinstellungen wieder her, damit spätere Beobachtungen den normalen Client beschreiben.