Zusammenfassung

  • RFC 10036 erschien im August 2026 auf dem IETF Standards Track und definiert das boolesche HTTP-Feld Incremental. Mit ?1 bittet ein Absender unterstützende Vermittler, den Inhalt einer Nachricht während des Empfangs weiterzugeben. Daraus folgt weder universelle Unterstützung noch ein Nachweis bis zum Client.
  • Ein unterstützender Vermittler soll zunächst den Header-Abschnitt senden und danach Inhaltsbytes fortlaufend freigeben, statt auf die vollständige Nachricht zu warten. Header, Trailer und kleine Inhaltsmengen dürfen weiterhin gepuffert werden. Wer das Feld versteht und die Betriebsart grundsätzlich ablehnt, muss einen Fehler erzeugen und darf Vollpufferung nicht als gewöhnlichen Erfolg tarnen.

Nehmen wir einen Überwachungsstrom, der alle drei Sekunden einen Befund liefert. Der Ursprung schreibt den ersten Befund sofort, ein Edge-Proxy reicht ihn weiter, doch eine nachgelagerte Sicherheitskomponente will vor jeder Freigabe den gesamten Response-Body prüfen. Der Stream ist auf unbestimmte Dauer angelegt. Ursprung, Proxy und Gateway melden weiter normale Aktivität; beim Nutzer kommt kein Befund an.

Das ist keine sprachliche Feinheit. Es ist die Trennung zwischen geäußerter Absicht und praktischer Kontrolle. Ein Header kann eine Anforderung transportieren. Die Freigabe eines Bytes bleibt eine Handlung des Systems, das den jeweiligen Puffer besitzt.

RFC 10036 setzt bei einer bewusst offenen Eigenschaft der HTTP-Semantik an. Empfänger dürfen Teile einer Nachricht während ihres Eingangs verarbeiten; Vermittler dürfen Nachrichten jedoch auch verzögern oder vollständig puffern. Vollständige Inspektion, Transformation, Effizienz und Verfügbarkeit können gute Gründe dafür sein. Für Anwendungen, die vor dem Nachrichtenende sichtbaren Fortschritt benötigen, kann dieselbe Entscheidung den Dienst funktionslos machen.

Server-Sent Events sind der einfache Fall: Eine lang offene Antwort trägt aufeinanderfolgende Ereignisse. Wer auf ihr Ende wartet, liefert keines davon. Der von RFC 10036 als laufende Arbeit zitierte Entwurf zu Chunked Oblivious HTTP Messages macht das gegenseitige Blockieren sichtbar: Soll eine Antwort beginnen, während der Request-Body noch wächst, kann Vollpufferung in nur einer Richtung den gesamten Austausch anhalten.

Die neue Spezifikation entzieht Vermittlern diese lokalen Entscheidungen nicht. Sie macht die Anforderung verständlich und legt fest, wie sich ein Empfänger verhalten soll, der sie versteht.

Ein Feldwert ist keine globale Betriebsart

Incremental ist ein Item gemäß Structured Field Values for HTTP. Zulässig sind ausschließlich boolesche Werte. Die positive Form lautet:

Incremental: ?1

Sie fordert inkrementelle Weitergabe an. Incremental: ?0 belässt den HTTP-Standardfall, in dem ein Vermittler die vollständige Nachricht puffern kann; der ausdrücklich negative Wert kann ihm diese Wahl sogar erleichtern. Fehlt das Feld, liegt nach RFC 10036 keine Anfrage vor. Hat es einen anderen Structured-Field-Typ, wird es ignoriert.

Die vier Zustände haben keine austauschbare Bedeutung. ?1 schaltet nicht beweisbar einen ganzen Pfad um. ?0 schreibt keinen Vollpuffer vor. Abwesenheit ist keine Ablehnung. Ein verworfener, falsch typisierter Wert beweist keine bewusste Gegenentscheidung. Betriebsdaten müssen deshalb den empfangenen Rohwert, das Parsergebnis, die Kenntnis der Implementierung und den gewählten Richtlinienpfad auseinanderhalten.

Im IANA-Register der HTTP-Feldnamen ist Incremental dauerhaft als strukturiertes Item eingetragen. Diese Registrierung schützt einen gemeinsamen Namen und seine Grammatik. Sie sagt nicht, welche installierte Version das Feld umsetzt oder wann sie zuletzt einen Body-Block freigegeben hat.

Request und Response treffen getrennte Entscheidungen

Das Feld gehört zu jeweils einer HTTP-Nachricht. Benötigt eine Anwendung sowohl einen schrittweise zum Server laufenden Request-Body als auch eine frühe, schrittweise Response, muss ?1 in beiden Nachrichten stehen. Der Request überträgt seine Präferenz nicht automatisch auf die Response. Ein Response-Header kann auch keinen vorgelagerten Request-Puffer nachträglich öffnen.

In Telemetrie verschwindet diese Unterscheidung oft hinter einer einzigen Kennzeichnung „Streaming aktiviert“. Dabei können beide Richtungen verschiedene Adapter, Sicherheitsregeln, Kapazitätsgrenzen und Upstream-Verbindungen durchlaufen. Ein Retry kann den Edge-Standort oder die Verbindung wechseln. Belastbare Aussagen benötigen Richtung, Nachrichtenkennung, Versuch und beobachteten Pfad.

Erhält ein unterstützender Vermittler ?1, soll er nicht bis zum vollständigen Body warten. Er soll den Header-Abschnitt weitergeben und danach Inhaltsbytes laufend senden. Die Spezifikation zieht aber eine klare Grenze: Das Feld betrifft Inhalt. Der komplette Header-Abschnitt und der komplette Trailer-Abschnitt dürfen gesammelt werden. „Inkrementell“ verspricht also nicht, dass jedes einzelne Oktett sofort ein eigenes Paket auslöst.

Auch HTTP-APIs sind lokale Grenzen. Eine Bibliothek kann eine Streaming-Schnittstelle anbieten, nachdem der vorgelagerte WAF den gesamten Body gesammelt hat. Umgekehrt kann ein Proxy zeitnah liefern, während das Anwendungsframework bis zu seinem eigenen Schwellwert wartet. Kein API-Name beweist das Verhalten der benachbarten Systeme.

Bewusste Unvereinbarkeit darf nicht wie Erfolg aussehen

Der stärkste Governance-Satz der RFC betrifft einen Vermittler, der das Feld versteht, aber nicht inkrementell weitergeben wird. Er muss eine Fehlerantwort erzeugen. Die Nachricht vollständig anzunehmen, lange zu speichern und schließlich normal weiterzuleiten, würde die ausdrückliche Anforderung in einen irreführenden Erfolg verwandeln.

Damit entstehen drei unterscheidbare Fälle. Ein älteres System kennt den Header nicht und kann ihn ignorieren. Ein unterstützendes System folgt ihm. Ein informiertes System lehnt ihn ab. Publikation allein rüstet alte Software nicht nach; die Regel verhindert aber, dass eine absichtliche Ablehnung unsichtbar bleibt.

Ein dauerhafter Konflikt besteht etwa bei einer Sicherheitsrichtlinie, die den ganzen Body sehen muss, bevor irgendein Inhalt freigegeben wird. Der Vermittler kann nicht zugleich vorab vollständig prüfen und bereits Daten nach außen senden. RFC 10036 empfiehlt hier 501 Not Implemented zusammen mit incremental_refused in Proxy-Status.

Das IANA-Register für Proxy-Status ordnet incremental_refused der empfohlenen 501-Antwort zu und beschränkt deren Erzeugung auf Vermittler. Der Fehler beschreibt damit eine Pfadentscheidung, nicht zwingend eine Ablehnung der fachlichen Operation durch den Ursprung.

Vorübergehende Knappheit braucht ein anderes Signal. Lang lebende inkrementelle Austausche beanspruchen Verbindungen, Slots, Speicher und Scheduler-Zeit. Ein Vermittler darf ihre Parallelität niedriger begrenzen, um gewöhnliche Requests zu schützen. Ist diese Grenze erreicht, empfiehlt RFC 10036 den aus RFC 6585 bekannten Status 429 Too Many Requests mit connection_limit_reached. Sicherheitskonflikt und Kapazitätsengpass in dieselbe Fehlerklasse zu legen würde jeden sinnvollen Retry untergraben.

Ein kleiner Puffer ist Teil des Vertrages

Jeden einzelnen Klein-Write sofort weiterzugeben kann Paket-, Weck- und Scheduling-Aufwand erhöhen. Ein Angreifer könnte winzige Schreibvorgänge gezielt als Kostentreiber einsetzen. RFC 10036 erlaubt deshalb eine begrenzte Sammlung bis zu einem Byte- oder Zeitschwellwert.

Begrenzt ist das entscheidende Wort. Größere Bündel können effizienter sein und zugleich die anwendungsrelevante Verzögerung erhöhen. Zwei Produkte können die Spezifikation unterstützen und dennoch sehr verschiedene Latenzprofile liefern. Der Mikropuffer gehört deshalb in die Produktentscheidung, nicht nur in eine versteckte Proxy-Konfiguration.

Auch „Time to First Byte“ genügt nicht. Ein Vermittler kann schnell einen ersten Block ausgeben und anschließend minutenlang schweigen. Regelmäßige Bytes können beim Client eintreffen, ohne ein vollständiges Ereignis zu bilden. Eine später erfolgreich abgeschlossene Nachricht kann jedes interaktive Ziel verletzt haben.

Zu erfassen sind Ende der Header, erstes Inhaltsbyte, weitere Byte-Fortschritte, längste Lücke, erstes verwendbares Anwendungsereignis, Trailer und Abschluss. Diese Zeitpunkte werden an mehreren Grenzen benötigt. Schreibzeit des Ursprungs, Sendezeit des Gateways und Verbrauchszeit des Clients sind keine Synonyme.

Proxy-Status ist Aussage, nicht Vollbeweis

RFC 9209 erlaubt Vermittlern, ihre Behandlung einer Response in Proxy-Status zu beschreiben. Die Einträge laufen vom ursprungsnahen zum nutzernahen Vermittler. Ein Fehler kann erklären, warum ein Proxy eine Antwort erzeugt hat; spätere Informationen lassen sich in manchen Fällen über Trailer ergänzen.

Das Verfahren bleibt absichtlich begrenzt. Vermittler entscheiden über die Ausgabe, dürfen Topologiedetails verbergen und müssen nicht jeden Parameter offenlegen. RFC 9209 weist zudem darauf hin, dass die Angaben nicht verifiziert sind. Ein Gerät kann ein Verhalten beschreiben, das sein Datenpfad nicht ausgeführt hat.

Ein konkretes incremental_refused ist daher wertvolle Evidenz für eine ausdrückliche Entscheidung. Sein Fehlen belegt keinen Support. Ein unwissender Hop erzeugt den Fehler nicht, Richtlinien können das Feld entfernen, Trailer können verloren gehen. Erst die Abstimmung von Feldwert, Parsergebnis, Richtlinie, Pufferschwellen, eingehenden und ausgehenden Bytes sowie Downstream-Beobachtung trägt die Aussage.

Der Header ersetzt keine Architekturentscheidung

Mit ?1 in Request und Response kann RFC 10036 einen bidirektionalen Byte-Kanal unterstützen und eine frühe Response vor Abschluss des Requests ermöglichen. Zugleich hält sie Extended CONNECT für HTTP/2 und Extended CONNECT für HTTP/3 für bidirektionale Protokolle im Allgemeinen für architektonisch passender.

Eine schrittweise konsumierte Repräsentation, ein Ereignisstrom und ein echtes Duplex-Protokoll haben unterschiedliche Lebenszyklen, Flusskontrollen und Fehlermodelle. Zwei lange Nachrichtenkörper können kurzfristig bequem sein und später schwer umkehrbare Ausnahmen in SDKs, Middleboxes und Kundenintegrationen erzeugen. Das Feld entscheidet diese Produktarchitektur nicht.

Vorwissen oder ein Probe kann Support für eine Ressource auf einem konkreten Pfad feststellen. Daraus entsteht kein zeitloses Merkmal. Routing, Inspektionsregeln, Versionen und Last ändern sich. Die Errata-Suche zu RFC 10036 zeigte bei der Prüfung am 30. August 2026 keinen Treffer; das ist ein datierter Registerstand, keine Zusage für die Zukunft.

Ein Beweis verbindet Absicht, Entscheidung und nutzbare Ankunft

Ein vertretbarer Datensatz hält Ressource, Richtung, Request- und Trace-Kennung, Versuch, HTTP-Version, Verbindungen, Route und Retry fest; den exakten Feldwert an jeder Grenze; Parsergebnis; Support- und Sicherheitsrichtlinienversion; Kapazitätsaufnahme; Byte- und Zeitgrenzen; Empfangs- und Ausgabezeiten; größte Lücke; erstes nutzbares Ereignis; Trailer, Abschluss, Abbruch, Reset, Status und Proxy-Status.

Tests müssen einzelne Bytes, langsame Ereignisse, Bursts, Backpressure, einen nie endenden Body, eine Vollinspektionsregel, erschöpfte Parallelität, Abbruch, Retry und Pfadwechsel enthalten. Ein schneller Laborstream über einen vereinfachten Pfad beweist nur diesen Versuch.

Heng Lus Primat des laufenden Codes verortet Autorität in der ausgeführten Folge statt im veröffentlichten Dokument. Minimale Anfangsspezifikation, lokalisierte künftige Entscheidung und freiwillige Übernahme erklären die Zurückhaltung des Standards: Ein gemeinsames Bit koordiniert das Nötige, während Sicherheit, Kapazität und Architektur lokal bleiben. Die Trennung zwischen technischer und praktischer Kontrolle zeigt, warum der Absender eine technisch gültige Präferenz äußern kann, ohne fremde Puffer praktisch zu kontrollieren.

RFC 10036 macht die Anforderung transportabel. Ob sie erfüllt wurde, entscheiden nur die beobachteten Freigaben im laufenden Pfad.