Zusammenfassung

  • RFC 9110 beschreibt Via als geordneten Nachweis der HTTP-Proxys und -Gateways, die eine bestimmte Nachricht weitergeleitet haben; Einträge dürfen Pseudonyme verwenden und unter engen Bedingungen zusammengefasst werden.
  • Ein vollständiger Pfad lässt sich erst belegen, wenn die unveränderten Anfrage- und Antwortfelder mit Ein- und Ausgangsprotokollen, Konfiguration, Tunneln, unteren Schichten, Umformungen und Zeiten verbunden werden.

Man stelle sich eine Störungsanalyse vor, in der eine Anfrage zwei Via-Einträge enthält. Das Dashboard zeichnet daraus zwei Zwischenstationen und erklärt, nur zwei Vermittler hätten die Transaktion berührt. Tatsächlich verbarg ein Firewall-Portal interne Namen hinter einem Pseudonym, zwei Gateways desselben Betreibers fassten gleichartige Protokolleinträge zusammen, ein Tunnel transportierte Bytes, ohne nach seinem Aufbau HTTP-Teilnehmer zu bleiben, und eine Umleitung auf einer unteren Schicht erschien nie im Feld.

Der Fall ist hypothetisch und berichtet nicht über einen bestimmten Anbieter. Er zeigt einen Beweisfehler: Einem Protokollfeld wird mehr Aussagekraft zugeschrieben, als seine Teilnehmer und Offenlegungsregeln liefern.

RFC 9110 unterscheidet Proxy, Gateway und Tunnel. Ein Proxy wird vom Client gewählt und leitet Nachrichten weiter. Ein Gateway tritt nach außen als Ursprungsserver auf und übersetzt oder leitet nach innen. Ein Tunnel wird zum blinden Relais zwischen Verbindungen und gilt nach Aktivierung nicht mehr als Beteiligter der HTTP-Kommunikation. Geräte auf unteren Schichten können Verkehr außerdem ohne Wissen der HTTP-Sender filtern oder umleiten. Ihr Einfluss erzeugt keinen Via-Eintrag.

Das Feld hat dennoch eine klare Funktion. In einer Anfrage zeigt es Zwischenprotokolle und Empfänger zwischen User Agent und Server; in einer Antwort zwischen Origin-Server und Client. Jedes Mitglied steht für einen Proxy oder ein Gateway, das diese Nachricht weiterleitete. received-protocol erfasst die vom vorgelagerten Absender verwendete Protokollversion; received-by bezeichnet den Empfänger, gegebenenfalls mit einem Pseudonym. Die Reihenfolge hilft beim Erkennen von Schleifen, beim Verfolgen der Weiterleitung und bei der Sichtbarkeit angekündigter Protokollfähigkeiten.

Die Pflichten sind asymmetrisch, und derselbe Vermittler kann seine Rolle von Anfrage zu Anfrage wechseln. Als Proxy muss er jeder weitergeleiteten Nachricht ein passendes Via hinzufügen. Als HTTP-zu-HTTP-Gateway — und nicht als aktiver Tunnel — muss er es bei eingehenden Anfragen hinzufügen; bei weitergeleiteten Antworten ist die Aufnahme dagegen fakultativ. Sobald er als aktiver Tunnel arbeitet, ist er nicht mehr Beteiligter der HTTP-Kommunikation. Die Antwortliste muss die Anfrageliste daher nicht spiegeln. Wer Zahlen ohne Richtung, Nachrichtenidentität, aktuelle Rolle und Messpunkt vergleicht, erfindet eine Symmetrie, die der Standard nicht verspricht.

Auch received-by ist kein festes Maschinenregister. Normalerweise enthält es Host und optionalen Port, kann bei sensiblen Angaben aber durch ein Pseudonym ersetzt werden. Ein Portal an einer Firewall sollte interne Hostnamen nur bei ausdrücklicher Freigabe übertragen. Softwarekommentare sind optional und dürfen vor der Weiterleitung entfernt werden. Da Via nicht authentisiert ist, bleibt ein Token eine Behauptung über die Weiterleitung; Beteiligung erfordert eine vertrauenswürdige Erfassung mit Integritätsnachweis. Allein bestimmt der Token weder routingfähige Adresse noch Maschine, Prozess oder Betreiber.

Selbst die Listenlänge braucht Kontext. RFC 9110 erlaubt das Zusammenfassen einer geordneten Teilfolge nur, wenn ihre Mitglieder denselben received-protocol-Wert haben; selbst dann sollte der Absender darauf verzichten, falls sie nicht zusätzlich derselben organisatorischen Kontrolle unterstehen oder ihre Hostwerte noch nicht durch Pseudonyme ersetzt wurden. Mitglieder mit unterschiedlichen Empfangsprotokollen dürfen nicht zusammengeführt werden. Gemeinsam angewandt erhalten diese Bedingungen die Protokollgrenze und erlauben nur die Verdichtung einer kontrollierten, pseudonymisierten internen Topologie. Ein sichtbares Mitglied kann mehrere Weiterleiter zusammenfassen.

Umformungen bilden eine eigene Beweisebene. Ein Proxy kann Felder oder Inhalte ändern. Ein Gateway kann zwischen HTTP und einem privaten Protokoll übersetzen. Ein Tunnel transportiert verschlüsselte Bytes, ohne Nachrichten oder interne Relais offenzulegen. Via erfasst Teilnahme an der HTTP-Weiterleitung, schreibt aber Inhaltsänderung, Cacheentscheidung, Sicherheitsprüfung, Lastverteilung oder physische Verbindung nicht vollständig zu.

Ein belastbares Prüfprotokoll zum Nachrichtenweg sollte die genaue Anfrage- und Antwortidentität, rohe Via-Werte an jedem Messpunkt, Protokoll und Richtung, die Zuordnung von Pseudonymen, Zusammenfassungsregeln, Ein- und Ausgangszeiten, Cache- und Umformungsentscheidungen, Tunnelenden und Beobachtungen unterer Schichten bewahren. „Nicht in Via sichtbar“ ist von „nicht im Pfad vorhanden“ zu trennen. Das Prüfprotokoll ist eine redaktionelle Betriebssynthese, kein IETF-Drahtobjekt.

Damit bleibt das Thema von benachbarten Arbeiten getrennt. Temporäre IPv6-Adressen betreffen Korrelation nach einem Kennungswechsel. BFD betrifft eingegrenzte Lebendigkeit und Routingwahl. HTTP Priority betrifft die Wirkung eines Planungswunsches. Via betrifft Herkunft und Vollständigkeit eines Nachrichtenweiterleitungsnachweises.

Quellen