Zusammenfassung

  • 103 Early Hints ist eine Informationsantwort und erlaubt Vorbereitung, während der Server die endgültige Antwort noch erzeugt.
  • Frühe Felder können sich ändern; der endgültige Status kann Erfolg, Umleitung, Clientfehler oder Serverfehler sein.
  • Ein Preload-Link beschreibt eine Beziehung zu einem Ziel, belegt aber weder erfolgreichen Abruf noch Berechtigung.
  • Monitoring muss die vollständige Antwortfolge und die Resultate spekulativer Abrufe erhalten, bevor es Verfügbarkeit ableitet.

Man stelle sich ein Auslieferungs-Dashboard vor, das den ersten gesehenen Status speichert. Der Edge sendet 103 Early Hints mit zwei Preload-Links, und die Anzeige wird grün. Kurz darauf endet dieselbe Anfrage mit 503 Service Unavailable; eines der vorab angeforderten Assets schlägt fehl. Die 103 war echt und potenziell hilfreich. Die Bereitschaftsaussage war es nicht.

RFC 8297 definiert Early Hints, um die Zeit zu nutzen, in der der Server seine endgültige Antwort vorbereitet. Der Client kann eine Verbindung öffnen oder ein wahrscheinlich benötigtes Stylesheet anfordern. Die Optimierung beginnt vor der Gewissheit – genau daraus entsteht ihr Nutzen.

Die Spezifikation sagt, der Server werde die angekündigten Felder wahrscheinlich in die endgültige Antwort aufnehmen. Üblicherweise wiederholt er sie, kann aber später erkennen, dass ein frühes Feld falsch oder nicht mehr sinnvoll war. Die endgültige Antwort darf die Angabe auslassen oder verändern. Eine Messung, die nur 103 speichert, beseitigt die beabsichtigte Unsicherheit.

Die Felder der 103 ersetzen die Felder der endgültigen Antwort nicht. Außerhalb der Leistungsoptimierung darf ihre Auswertung die Verarbeitung der endgültigen Antwort nicht verändern. Preload bereitet vor; er gewährt keinen Zugang, wählt keine Darstellung und verwandelt eine ausstehende Entscheidung nicht in Erfolg.

RFC 9110 beschreibt das Gesamtmodell: Zu einer Anfrage gehören null oder mehrere vorläufige 1xx-Antworten, gefolgt von genau einer endgültigen Antwort aus einer anderen Klasse. 1xx meldet Fortschritt, 2xx Erfolg, 3xx Umleitung, 4xx einen Clientfehler und 5xx einen Serverfehler. Wer 103 als Erfolg wertet, komprimiert eine geordnete Folge zu früh in ein einzelnes Signal.

Selbst eine endgültige Antwort kann das Nutzerergebnis unvollständig abbilden. Ein 200-Dokument kann auf ein Asset verweisen, das später scheitert, zu spät eintrifft, die Integritätsprüfung verfehlt oder durch Richtlinien blockiert wird. Eine anonyme Sonde kann andere Inhalte als eine authentifizierte Sitzung erhalten. Deshalb muss die Antwortkette mit dem tatsächlich gewünschten Ergebnis verbunden werden.

RFC 8288 definiert Web Links als typisierte Beziehungen zwischen einer Kontextressource und einem Ziel. Ein Link-Feld mit preload-Beziehung bezeichnet Ziel und Verarbeitungsabsicht. Es bestätigt weder DNS-Auflösung, Verbindung, TLS und Autorisierung noch Cache-Eignung, Objektintegrität oder erfolgreichen Transfer.

Auch der Beobachtungspunkt gehört zum Beleg. Wenn Browser, CDN, Reverse Proxy oder synthetische Sonde eine 103 sehen, zeigt das, dass diese Informationsantwort in diesem Austausch bis zu diesem Beobachter gelangte. Es benennt nicht automatisch den Urheber jedes Feldes und sagt nichts Verlässliches über eine andere Region, HTTP-Version, Cache-Lage oder Identität.

Spekulation kostet Ressourcen. Ein unnötiger Preload verbraucht Verbindungen, Bandbreite, Geräteenergie und Cache-Platz. RFC 8297 begrenzt frühe Verarbeitung, weil eine Leistungsoptimierung Sicherheits- und Datenschutzwirkungen haben kann. Early Hints abzuschalten wäre die falsche Lehre; sein Umfang, Aufwand und Ergebnis müssen sichtbar bleiben.

Ein HTTP-Antwortkettenbeleg sollte Methode und Ziel, Protokoll, Verbindung und Beobachtungspunkt enthalten; jede Informationsantwort in Reihenfolge; endgültigen Status und Felder; sowie, soweit möglich, den Hash der Darstellung. Für jedes spekulative Ziel gehören Beziehung, auslösende 103, Übermittlungsmodus für Anmeldedaten, Cache-Ergebnis, Endstatus, Integrität und Dauer dazu. Intermediär- oder Cache-Identität, Autorisierungskontext und Zeitpunkt ergänzen den Beleg ohne Geheimnisse zu speichern.

Das Dashboard kann dann zwischen „103 beobachtet“, „Preload gestartet“, „endgültige 200 empfangen“, „Darstellung geprüft“ und „Anwendungstransaktion abgeschlossen“ unterscheiden. Alle Ereignisse dürfen gemeinsam angezeigt werden, doch das erste darf die anderen nicht erzeugen.

Die Trennung verbessert die Diagnose. Kommt 103 früher, die endgültige Antwort aber später, liegt das Problem womöglich in später Anwendungsarbeit. Scheitern Assets nur an einem Edge, kommen Pfad, Cache oder Deployment infrage. Ändert sich die finale Link-Menge, kann eine späte Inhalts-, Routing- oder Autorisierungsentscheidung vorliegen. Die verantwortlichen Stellen unterscheiden sich.

Innerhalb seiner Grenze ist Early Hints wertvolle Evidenz. Es zeigt, dass eine beobachtete HTTP-Kette den Punkt erreicht hat, an dem vorläufige Beziehungen mitgeteilt werden konnten, und macht verschwendete Vorabrufe sowie Edge-Abweichungen sichtbar. Die noch nicht eingetroffene endgültige Antwort kann es nicht versprechen.

Quellen

RFC 8297 — An HTTP Status Code for Indicating Hints; RFC 9110 — HTTP Semantics; RFC 8288 — Web Linking.