Zusammenfassung

  • Eine 103-Antwort kündigt Felder an, die der Server in der endgültigen Antwort erwartet. Sie kann einen reversiblen Abruf wie preload vorziehen, ersetzt die endgültigen Felder aber nicht; diese dürfen den Hinweis auslassen oder ändern.
  • Der Empfänger braucht ein eigenes Spekulationsbudget. Ein früher Hinweis beweist weder Urheberschaft noch Autorisierung, Zustimmung oder Cache-Fähigkeit und darf keine unumkehrbare Wirkung freigeben.

Early Hints ist gerade dann nützlich, wenn der Server seine Antwort noch nicht kennt. Vielleicht steht bereits fest, dass eine Seite wahrscheinlich ein Stylesheet braucht, während eine Datenbankabfrage noch läuft. Der Server schickt 103 Early Hints mit einem Link, und der Browser kann den Abruf beginnen, statt untätig auf das Dokument zu warten.

Wären alle Felder sicher, könnte der Server die endgültige Antwort senden. Der Zeitgewinn entsteht also nicht durch vorgezogene Gewissheit, sondern durch begrenzte Unsicherheit. Der Client investiert früh und akzeptiert, dass ein Teil der Arbeit vergeblich sein kann.

RFC 8297 hält diese Investition klein. Es standardisiert eine Prognose, keine Weisung. Der Absender kann Hinweise anbieten, der Empfänger darf sie ignorieren, und die spätere Antwort behält ihre eigene Autorität.

HTTP ordnet Zwischenstand und Ergebnis

Nach RFC 9110 kann auf eine Anfrage zunächst keine, eine oder mehrere informative 1xx-Antworten folgen, bevor genau eine endgültige Nicht-1xx-Antwort eintrifft. Eine 1xx-Antwort endet mit ihrem Feldabschnitt; Inhalt und Trailer hat sie nicht. Clients müssen auch unerwartete Informationsantworten verarbeiten können, wobei ein User Agent sie ignorieren darf.

Status 103 liegt in diesem Zwischenraum. Er sagt, der Server werde die enthaltenen Felder wahrscheinlich in der endgültigen Antwort senden. Gewöhnlich wiederholt er sie. Während der weiteren Arbeit kann sich jedoch zeigen, dass ein frühes Feld falsch oder nicht mehr erwünscht ist.

RFC 8297 zieht deshalb zwei deutliche Grenzen. Die frühen Felder sind Hinweise und ersetzen die endgültigen Felder nicht. Außer für Leistungsoptimierung darf ihre Auswertung nicht verändern, wie die endgültige Antwort verarbeitet wird. Die Felder sind auch keine Metadaten über die 103-Antwort selbst.

Das Dokument zeigt eine Folge aus zwei 103-Antworten. Zusammen kündigen sie drei Links an; die endgültige Antwort behält zwei und ersetzt den dritten. Das ist kein Ausnahmefehler, sondern die beabsichtigte Korrekturmöglichkeit.

Interne Systeme sollten die Blöcke daher nicht vorschnell zu einer „vorläufigen Endantwort“ verschmelzen. Ein solcher Begriff suggeriert, nur die Unterschrift fehle noch. Tatsächlich liegen mehrere zeitlich geordnete Prognosen und danach eine semantisch getrennte Antwort vor.

Was früh fehlt, ist später nicht ausgeschlossen

Der Server darf nur einen Teil der erwarteten Felder offenlegen. Er kann weitere 103-Antworten senden, sobald neue Informationen entstehen, und muss zuvor gesendete Felder nicht jedes Mal wiederholen. Der Client darf die empfangenen Mengen gemeinsam betrachten.

Er darf aus der Abwesenheit eines Feldes jedoch nicht schließen, dass es auch im Ergebnis unwahrscheinlich sei. Early Hints ist ein positiver Teilkanal. Schweigen enthält keine negative Zusage.

Das ist besonders bei Cache-Vorgaben, Sicherheitsfeldern und Authentifizierungsanforderungen wichtig. Fehlen sie im ersten Hinweis, entsteht daraus keine Erlaubnis, die endgültigen Regeln vorwegzunehmen oder Schutzmaßnahmen zu lockern.

Eine Pflicht zur vollständigen Vorabantwort würde zwar Unsicherheit reduzieren, aber den Zweck aufheben. Der Server müsste erst genau jene Berechnung abschließen, die parallel zum frühen Abruf laufen soll. Unvollständigkeit ist keine Panne, sondern eine Kostenfrage für den Empfänger.

Die richtige Betriebsfrage lautet deshalb nicht, ob man 103 „vertraut“. Sie lautet, was ein Irrtum kostet. Ein abbrechbarer Abruf einer kleinen öffentlichen Datei hat ein anderes Risikoprofil als eine Bestandsreservierung, Kontoänderung, Geheimnisweitergabe oder Zahlung.

preload bezeichnet eine Beziehung, keinen Befehl

Das typische Beispiel verwendet das Feld Link mit der Relation preload. Web Linking liefert die gemeinsame Bedeutung einer Beziehung zwischen Ziel und Kontext. Ein geeigneter Client kann erkennen, dass ein früher Abruf des Ziels bei der späteren Verarbeitung helfen könnte.

Die Relation verpflichtet nicht jeden Empfänger zur gleichen Handlung. Ein Gerät mit teurem Datenvolumen kann sie ignorieren. Ein Browser kann Ressourcentypen und Ziele begrenzen. Eine Organisation kann Spekulation über Ursprungsgrenzen hinweg untersagen. Gemeinsam ist die Lesbarkeit des Signals, nicht das auszugebende Budget.

Auch ein spekulativer Abruf ist eine echte Netzaktivität. Er verbraucht Bandbreite, belegt Verbindungen, erreicht einen Dienst, wärmt Caches auf und offenbart Interesse an einer Adresse. Je nach normalen Plattformregeln können Anmeldedaten beteiligt sein. Das frühe Eintreffen hebt keine Origin-, Berechtigungs-, Credential- oder Größenregeln auf.

Selbst ein erfolgreicher Download sagt nichts Endgültiges über die Hauptanfrage. Deren Ergebnis kann ein Fehler, eine Umleitung oder eine Authentifizierungsaufforderung sein. Der Link kann verschwinden. Die lokale Verfügbarkeit eines Objekts ist keine Genehmigung, es auszuführen, anzuzeigen oder anderweitig zu verwenden.

Die Leitlinie ist knapp: 103 darf eine Tätigkeit vorziehen, die aus einem unabhängigen Grund bereits erlaubt ist. Der Hinweis selbst darf diese Erlaubnis nicht erzeugen.

Ein Vermittler kann den ersten Hinweis erzeugen

Das zuerst sichtbare Feld muss nicht vom Anwendungsserver stammen. RFC 8297 beschreibt einen Cache-Vermittler, der aus den Feldern einer veralteten gespeicherten Antwort eine 103-Nachricht erzeugt. Während der Revalidierung kann er anschließend eine weitere 103 und die endgültige Antwort vom Origin weiterleiten.

Das nutzt Wissen in Nutzernähe und spart möglicherweise Zeit. Zugleich zeigt es die Herkunftsgrenze: Der erste Link kann die Erinnerung des Randknotens ausdrücken, nicht die aktuelle Einschätzung der Anwendung. Empfang allein beweist weder den Autor noch spätere Bestätigung.

RFC 9110 verlangt grundsätzlich, dass ein Proxy 1xx-Antworten weiterleitet, sofern er die Erzeugung der betreffenden Informationsantwort nicht selbst angefordert hat. Die Regel sichert den Transport. Sie macht den Weiterleiter nicht zur endgültigen semantischen Instanz.

Betreiber von CDN, Gateway und Anwendung sollten festhalten, welche Schicht 103 erzeugen darf, aus welchem Cachezustand, mit welchem Höchstalter und wie sie ihre Prognose gegen das Ergebnis prüft. Der Client sieht diese Kette womöglich nicht vollständig. Daher muss seine Frühhandlung auch bei unklarer Herkunft sicher bleiben.

Auch Telemetrie sollte einen möglichen Edge-Hinweis nicht pauschal als „Aussage des Servers“ verbuchen. Sonst erscheint eine veraltete Randprognose fälschlich als Meinungswechsel der Anwendung.

Wer „informativ“ übersieht, verliert Nachrichtengrenzen

Die Sicherheitsbetrachtung von RFC 8297 nennt ein konkretes HTTP/1.1-Risiko. Ein fehlerhafter Client könnte 103 als endgültige Antwort ansehen. Auf einer dauerhaften Verbindung ordnet er dann womöglich Antworten auf spätere Anfragen der vorherigen Antwort zu. Werden darüber verschiedene Ursprünge zusammengeführt, kann die Verwechslung Informationen ursprungsübergreifend offenlegen.

„Informativ“ ist folglich keine redaktionelle Abschwächung, sondern Teil der Nachrichtenintegrität. RFC 9112 ordnet jede empfangene Antwort der ersten offenen Anfrage zu, die noch keine endgültige Nicht-1xx-Antwort erhalten hat. Mehrere Antwortnachrichten gehören nur dann zu einer Anfrage, wenn Informationsantworten dem Ergebnis vorausgehen.

RFC 8297 weist deshalb darauf hin, dass ein Server 103 über HTTP/1.1 unterlassen kann, solange er die korrekte Verarbeitung durch den Client nicht kennt. Bei HTTP/2 gilt dieser konkrete Framing-Fehler als weniger wahrscheinlich: Zwischenantworten sind Feldblöcke auf einem Stream, und ein Block mit Informationsstatus darf den Stream nicht beenden. HTTP/3 erlaubt ebenfalls 1xx vor der endgültigen Antwort und schließt Inhalt und Trailer darin aus.

Saubereres Framing verhindert nicht jede Fehlentscheidung. Ein HTTP/3-Client kann jedes Frame korrekt lesen und einen Hinweis trotzdem fälschlich als Zustimmung interpretieren. Transportstruktur und Handlungsbefugnis brauchen getrennte Kontrollen.

Ein Cache erinnert sich, entscheidet aber nicht

Ein Cache ist schnell, weil er Vergangenes kennt. Diese Evidenz kann sehr gut und dennoch veraltet sein. Ein gestern benötigtes Skript kann heute fehlen; die Revalidierung kann zu einem anderen Status oder zu anderen Abhängigkeiten führen.

RFC 9111 trennt Frische, Validierung, Speicherung und Wiederverwendung. Ein durch 103 ausgelöster Abruf bestimmt nicht, ob die endgültige Antwort speicherbar, frisch oder für die aktuelle Anfrage anwendbar ist. Ein aufgewärmtes Objekt verpflichtet die endgültige Darstellung nicht, darauf zu verweisen.

Sinnvolle Messung trennt mindestens: Hinweis gesendet, empfangen, Relation erkannt, Abruf gestartet, Feld im Ergebnis bestätigt und Ressource tatsächlich genutzt. Eine einzige Erfolgsquote verbirgt verworfene Bytes, Doppelabrufe, Verbindungsdruck, Datenschutzkosten und zusätzliche Origin-Last.

Die Anreize sind verteilt. Die Website profitiert von schneller Darstellung, der Nutzer bezahlt unnötige Daten. Der Edge möchte seinen Cache verwerten, während der Origin zusätzliche Abrufe verarbeitet. Ein Budget auf der Empfängerseite verhindert, dass eine lokale Optimierung ihre Kosten unbemerkt exportiert.

Ein kleines gemeinsames Protokoll lässt lokale Wahl

Das IANA-Register führt 103 als Early Hints und verweist auf RFC 8297. Das Dokument wurde 2017 als experimentelles IETF-Protokoll veröffentlicht. Es beruht auf IETF-Konsens, öffentlicher Prüfung und IESG-Freigabe, gehört aber nicht zum Internet Standards Track. Daraus folgt kein universeller Einführungsauftrag.

Die gemeinsame Schicht bleibt bewusst klein: ein Zwischenstatus, normale HTTP-Felder, die Position vor dem Ergebnis und die Nicht-Ersetzung der endgültigen Felder. Darauf können unterschiedliche Strategien aufbauen, ohne die Verständlichkeit des Signals zu verlieren.

Ein Browser kann nur bekannte Relationen nutzen. Ein eingeschränktes Gerät kann alles ignorieren. Eine Unternehmensrichtlinie kann externe Ziele sperren. Ein Cache kann Hinweise nur bei jüngst hoher Trefferquote erzeugen. Keine zentrale Stelle muss jeden einzelnen Abruf freigeben.

Das entspricht der Folge von Lu Heng: minimale Anfangsspezifikation, lokal getroffene spätere Entscheidungen und informierte freiwillige Übernahme. Der Server kennt seinen Rechenfortschritt, der Vermittler das Alter seines Cachewissens, der Client Netzpreis, Ressourcen und Credentials. Die jeweilige Entscheidung bleibt dort, wo ihre Folgen sichtbar sind.

Eine zentrale Genehmigungsstelle pro Hinweis würde einen Teil des Zeitgewinns aufzehren. Statt Regellosigkeit braucht es vorab definierte lokale Grenzen: verstandene Relationen, zugelassene Ursprünge, Datenobergrenzen, Credential-Verhalten und Wirkungen, die niemals spekulativ beginnen.

Ein Spekulationsbuch statt einer Schattenantwort

Eine belastbare Implementierung speichert jede 103-Antwort geordnet und getrennt vom Ergebnis. Sie verbindet das auslösende Feld mit Anfrage, HTTP-Version und angewendeter lokaler Regel. Ein neuer Hinweis überschreibt die alte Prognose nicht.

Danach klassifiziert sie Wirkungen nach dem möglichen Verlust. Öffentliche, begrenzte und abbrechbare Abrufe können ein Budget erhalten. Zustandsänderung, Werttransfer, Informationsfreigabe, Zustimmung und Zugriffsänderung warten auf ihre normale Autorisierung.

Mit der endgültigen Antwort folgt die Abstimmung: Welche Felder wurden wiederholt, ausgelassen oder geändert? Welche Aufgaben bleiben nützlich, welche werden abgebrochen? Wie viel Zeit wurde gewonnen und wie viel Ressource verschwendet? Die endgültigen Felder steuern die Verarbeitung; die frühen Daten erklären Prognosequalität.

Schließlich muss Ignorieren möglich bleiben. Wird eine Version, ein Vermittler oder ein Netz riskant, kann der Client seine Reaktion auf 103 stoppen und die endgültigen Antworten weiterhin korrekt verarbeiten.

Early Hints beansprucht nicht, die Zukunft zu kennen. Es macht unvollständige Information brauchbar, ohne sie zu überhöhen. Früh teilen, Verlust lokal begrenzen und die letzte Autorität bei der abgeschlossenen Entscheidung belassen: Gerade diese Zurückhaltung schafft Geschwindigkeit ohne Zentralisierung.

Quellen