Webaufrufe verstehen und Fehler eingrenzen

Voraussetzungen und Lernziele

Du kannst einen Browser bedienen und eine URL lesen. Nach dieser Lektion kannst du DNS, Transport, TLS und HTTP als unterschiedliche Schritte eines Webaufrufs erklären. Du kannst eine fehlgeschlagene Anfrage nach Schichten untersuchen und Beobachtung von Vermutung unterscheiden. Aufwand: 90 Minuten, davon etwa 45 Minuten für eigene Beobachtungen.

Eine Adresse ist noch keine Verbindung

Du öffnest https://example.org/lernen. Die URL benennt ein Schema, einen Hostnamen und einen Pfad. Der Hostname muss einer erreichbaren Adresse zugeordnet werden. Dafür wird in der Regel DNS verwendet; zwischengespeicherte Antworten können eine erneute Anfrage vermeiden. Eine passende DNS-Antwort beweist aber weder, dass ein Webserver erreichbar ist, noch dass dieser die gewünschte Website kennt.

Danach braucht der Browser eine geeignete Verbindung. Bei HTTP/1.1 und HTTP/2 wird normalerweise TCP verwendet; HTTP/3 verwendet QUIC. Für eine HTTPS-Anfrage muss zudem die verschlüsselte Kommunikation samt Serveridentität geprüft werden. Ein Zertifikat muss unter anderem zum angefragten Namen passen und innerhalb seiner Gültigkeit liegen. Ein fehlender HTTP-Status kann daher völlig unabhängig von der Anwendung entstehen.

Erst wenn eine Anfrage den zuständigen Webdienst erreicht, kann sie dort einen HTTP-Status erhalten. «DNS funktioniert» und «die Seite funktioniert» sind also unterschiedliche Aussagen.

URL
 ├─ Name auflösen: Welche Adresse?
 ├─ Verbindung aufbauen: Dienst erreichbar?
 ├─ HTTPS aushandeln: Identität und Verschlüsselung korrekt?
 └─ HTTP austauschen: Welche Ressource und welche Antwort?

Das Diagramm ist eine Denkstütze. Moderne Browser verwenden Verbindungen erneut und können Schritte parallelisieren. Bei QUIC sind Transport und TLS enger verbunden. Für die Fehlersuche bleibt die Frage nützlich, welcher Nachweis tatsächlich vorliegt.

Anfrage und Antwort lesen

Eine vereinfachte HTTP/1.1-Anfrage könnte so aussehen:

GET /lernen HTTP/1.1
Host: example.org
Accept: text/html

Die Antwort enthält einen Status, Header und gegebenenfalls einen Inhalt:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: private, no-store

<!doctype html>...

GET fragt eine Darstellung ab. Der Pfad benennt die Ressource innerhalb des angesprochenen Hosts. Der Host ist wichtig, weil dieselbe IP-Adresse viele Websites bedienen kann. Bei HTTPS wird der gewünschte Servername bereits während der Aushandlung berücksichtigt; nur die IP im Browser zu öffnen ist deshalb kein gleichwertiger Test einer Domain.

Der Status beschreibt das Ergebnis dieser HTTP-Anfrage. 200 bedeutet nicht, dass jede angezeigte Information fachlich richtig ist. 404 ist dagegen bereits eine Antwort eines HTTP-Dienstes: Die Anfrage ist weit genug gelangt, damit dieser die Ressource als nicht gefunden melden kann. Eine Zertifikatsfehlermeldung vor einer HTTP-Antwort ist eine andere Fehlerklasse.

Ein systematisches Protokoll

Halte vor jeder Änderung fest: Zeitpunkt, genaue URL ohne geheime Token, beobachtetes Ergebnis, erwartetes Ergebnis und Testumgebung. Ändere anschliessend möglichst nur einen relevanten Faktor. So kannst du eine Verbesserung einer Ursache zuordnen.

Angenommen, eine Subdomain zeigt auf die richtige IPv4-Adresse, HTTPS scheitert aber. Mögliche Hypothesen sind ein fehlender virtueller Host oder eine unpassende TLS-Konfiguration. Ein alter AAAA-Eintrag könnte zusätzlich manche Geräte zu einer anderen IPv6-Adresse führen. Keine dieser Vermutungen ist durch den A-Eintrag allein bewiesen.

Ein gutes Protokoll lautet: «DNS liefert Adresse X; beim HTTPS-Aufbau bricht die Verbindung vor einem HTTP-Status ab.» Ein schlechtes Protokoll lautet: «Die Datenbank ist kaputt», obwohl noch gar keine Anfrage die Anwendung erreicht hat.

Häufige Missverständnisse

• Ein DNS-Wechsel wirkt nicht bei allen Resolvern gleichzeitig. Cachezustand und Ablaufzeiten gehören zur Untersuchung.
• Ein gültiges Zertifikat macht eine Anwendung nicht automatisch sicher. Autorisierung, Eingabeprüfung und Betrieb bleiben notwendig.
• Eine erfolgreiche Startseite prüft keinen Passwortreset. Unterschiedliche Pfade können unterschiedliche Komponenten verwenden.
• Ein HEAD-Test prüft nicht den gesamten Inhalt einer normalen GET-Antwort. Manche Anwendungen behandeln die Methoden unterschiedlich.

Verständnisfragen mit Erklärung

Kann eine falsche Route einen TLS-Fehler verursachen? Eine normale Anwendungsroute wird erst nach dem HTTPS-Aufbau verarbeitet. Ein vorgelagerter Namens- oder Zertifikatsfehler muss zunächst davor untersucht werden.

Warum reicht eine erreichbare IP nicht aus? Auf derselben IP können mehrere virtuelle Hosts liegen. Der angefragte Name beeinflusst die Auswahl des Zertifikats und der Anwendung.

Beweist ein 500-Status einen Datenbankfehler? Nein. Er weist auf einen internen Fehler bei der Bearbeitung hin. Erst passende, zeitlich zugeordnete Serverbeobachtungen können die Ursache eingrenzen.

Übung: Vier Beobachtungen zuordnen

Ordne zu und benenne den nächsten möglichst kleinen Test:

1. Der Hostname ist nicht auflösbar.
2. Die Verbindung wird bereits vor einer HTTP-Antwort abgelehnt.
3. Der Browser meldet einen unpassenden Zertifikatsnamen.
4. Die Startseite funktioniert; /kurs/42 liefert 404.

Transferaufgabe

Öffne die Netzwerkansicht der Entwicklerwerkzeuge und lade eine eigene oder ausdrücklich zum Test freigegebene Seite neu. Notiere Dokumentanfrage, Status, Inhaltstyp und zwei weitere Ressourcen. Entferne vor dem Teilen Cookies, Zugangstoken und personenbezogene Inhalte. Formuliere drei belegte Beobachtungen und eine noch ungeprüfte Hypothese. Erkläre, welcher nächste Test die Hypothese widerlegen könnte.

Zusammenfassung

Webaufrufe verbinden Namensauflösung, Verbindungsaufbau, TLS und HTTP. Untersuche zuerst den frühesten nicht bestätigten Schritt. Ein belastbares Fehlerprotokoll benennt Beobachtungen und passende Gegenproben, statt vorschnell die Anwendung oder Datenbank verantwortlich zu machen.

Quellen und Prüfung

Primärquellen zuletzt inhaltlich konsultiert am 8. November 2026. Versionsangaben beachten; eine Dokumentationsseite kann sich später ändern.

• MDN: Overview of HTTP

Konto erstellen, um deinen Bearbeitungsstand zu speichern.