Zusammenfassung

  • RFC 10036 definiert das boolesche HTTP-Feld Incremental. Der wahre Wert fordert informierte Zwischenstellen auf, Inhalte während ihres Eingangs weiterzuleiten. Lehnt eine solche Stelle diesen Modus grundsätzlich ab, muss sie mit einem Fehler antworten, statt die ganze Nachricht still anzunehmen und zu puffern.
  • Das Feld ist weder Fähigkeitsaushandlung noch Zustellbestätigung. Eine unwissende Zwischenstelle darf es ignorieren, Anfrage und Antwort benötigen eigene Signale, und begrenztes Sammeln nach Bytezahl oder Zeit bleibt erlaubt. Tatsächlicher Fortschritt muss deshalb an jedem Hop gemessen werden.

Eine richtige Entscheidung an einem Hop reicht nicht bis zum Nutzer

Der endlose Ereignisstrom trennt lokale Behandlung von Ende-zu-Ende-Wirkung. Der erste Proxy kann seinen inkrementellen Modus wählen, weil er das Feld versteht. Der zweite sieht nur ein unbekanntes Feld und arbeitet wie bisher. Wenn seine normale Strategie auf das Ende des Bodys wartet, wartet sie bei dieser Antwort unbegrenzt.

RFC 10036 enthält keine positive Bestätigung aller Zwischenstellen. Das Feld am Ausgang des Ursprungs belegt nur die Absicht des Senders. Frühe Bytes hinter einem Proxy belegen nur diesen Abschnitt. Auch ein Status 200 beweist nicht, dass der erste Nutzinhalt den Client erreicht hat.

Die Fragestellung ist nicht mit HTTP Priority gleichzusetzen. Priorität ordnet bereits sendefähige Bytes unter Konkurrenz. Incremental fragt, ob eine Nachricht einen Hop schon vor ihrem letzten Byte durchqueren soll. Ein Pfad kann früh weiterleiten und dennoch wenig Kapazität zuteilen. Er kann hohe Priorität vergeben, während ein späterer Proxy bis zum Nachrichtenende puffert.

Ein enger Vertrag macht eine verborgene Wahl prüfbar

Der RFC Editor veröffentlichte RFC 10036 im August 2026 als IETF Standards Track. Die Arbeit entstand in der HTTP Working Group. IANA führt Incremental nun dauerhaft als HTTP-Feld vom Structured-Fields-Typ Item und incremental_refused als HTTP-Proxy-Fehlertyp.

Die Syntax ist absichtlich klein. ?1 verlangt inkrementelle Weiterleitung. ?0 belässt es beim Standardverhalten und kann einer Zwischenstelle mehr Sicherheit geben, dass vollständiges Puffern zulässig ist. Andere Werttypen werden ignoriert. Unbekannte Parameter werden ebenfalls ignoriert und machen aus dem booleschen Signal keine allgemeine Verhandlung.

Der Geltungsbereich ist eine einzelne HTTP-Nachricht. Soll ein Upload weiterlaufen, während die Antwort bereits fließt, brauchen Anfrage und Antwort jeweils ihren eigenen wahren Wert. Das Feld in einer Richtung entscheidet nicht über die andere.

Nimmt eine informierte Zwischenstelle die Bitte an, soll sie den Header-Abschnitt senden und Inhaltsbytes fortlaufend beim Eingang weiterreichen, statt auf den gesamten Inhalt zu warten. Einen vollständigen Header- oder Trailer-Abschnitt darf sie weiterhin sammeln. Geregelt wird der Weiterleitungsmodus des Inhalts, nicht jede Verarbeitungsgrenze.

Eine ausdrückliche Ablehnung liefert verwertbare Evidenz

Manche Sicherheitsfunktionen benötigen die vollständige Nachricht, bevor sie deren Freigabe beurteilen können. Das Feld gibt dem Sender keine Befugnis, diese Prüfung zu umgehen. Es zwingt eine informierte Zwischenstelle vielmehr zu einer klaren Wahl: inkrementell weiterleiten oder ablehnen, statt anzunehmen und dann bis zum Ende zu schweigen.

Bei dauerhafter Unvereinbarkeit mit einer Inhaltsprüfung empfiehlt RFC 10036 eine 501-Antwort zusammen mit dem Proxy-Status-Fehler incremental_refused. So wird aus einem unsichtbaren Stillstand eine klassifizierte Ablehnung. Betreiber können sie von Ursprungsverzögerung und Transportverlust trennen.

Ein vorübergehendes Kapazitätsproblem erhält ein anderes Signal. Lange inkrementelle Anfragen binden Verbindungen und parallelen Zustand. Eine Zwischenstelle darf sie enger begrenzen, um andere Nutzer zu schützen. Ist das Kontingent erschöpft, lautet die Empfehlung 429 mit Proxy-Status connection_limit_reached.

Diese Angaben beschreiben nicht automatisch den gesamten Pfad. Details können zum Schutz interner Topologie fehlen, ein weiterer Proxy kann Proxy-Status entfernen, Trailer können verloren gehen. Ein belastbarer Befund verbindet das Signal mit der meldenden Stelle, ihrer Richtlinie, ihrem Kapazitätszustand und lokaler Telemetrie.

Inkrementell bedeutet nicht pufferlos

Jedes winzige Fragment als eigenen Schreibvorgang weiterzugeben, verschwendet CPU, Bandbreite und nachgelagerte Arbeit. Der Standard erlaubt deshalb ein kleines Sammelfenster. Eine Implementierung kann bei einem Byte-Schwellenwert oder nach einem kurzen Zeitlimit senden.

Entscheidend ist die endliche Grenze, die nicht vom Nachrichtenabschluss abhängt. 16 Kilobyte und ein 20-Millisekunden-Timer ergeben eine messbare Latenzhülle. „Bis der Body endet“ ergibt keine, wenn der Strom stundenlang offen bleiben kann.

Der Wert ?1 verrät diese Grenzen nicht. Er verlangt keine sofortige Paketausgabe, reserviert keine Bandbreite und umgeht weder Fluss- noch Überlastkontrolle. HTTP-Bibliothek, Proxy, TLS, Kernel und Transport können nach der Moduswahl jeweils weitere Verzögerung einführen.

Ein sinnvolles Betriebsziel misst daher Zeit und Bytes zwischen Eingang auf einer Hop-Seite und erstem sowie fortlaufendem Ausgang auf der anderen. Es nennt Nachrichtengrößen, Ereignistakt, gleichzeitige Last und Fehlerbedingungen. Die Aussage „Puffer deaktiviert“ ersetzt keine beobachtete Verteilung.

Die unwissende Zwischenstelle bleibt die harte Grenze

Eine Stelle, die das Feld versteht, muss bei vollständiger Ablehnung einen Fehler liefern. Eine Stelle, die es nicht versteht, kann dieser Regel nicht folgen. Sie darf es ignorieren und genau wie zuvor puffern.

Darum verweist die Spezifikation auf Vorwissen oder ressourcenspezifische Sondierung. Das Feld koordiniert kompatible Implementierungen, entdeckt aber keine universelle Fähigkeit. Ein erfolgreicher Test für eine URL, einen POP, eine HTTP-Version oder Route ist kein dauerhafter Beleg für eine andere.

Pfade verändern sich. Ein CDN fügt eine Sicherheitsstufe hinzu, verteilt Verkehr auf Softwaregenerationen, verschiebt einen Mandanten zu einem anderen Gateway oder handelt upstream eine andere HTTP-Version aus. Ein Ursprung-Edge-Test übersieht womöglich den Puffer zwischen Edge und Client. Eine kleine, endende Antwort reproduziert nicht den unbegrenzten Stillstand eines echten Stroms.

Fähigkeitsevidenz benötigt deshalb Pfad und Zeitpunkt. Aufzuzeichnen sind DNS- und Routing-Auswahl, Proxy-Identitäten, HTTP-Versionen, Konfigurationsstände, Felderhalt, Puffergrenzen, Zeiten von erstem Header und Inhalt, fortlaufender Takt und die Client-Beobachtung.

Lange und bidirektionale Anwendungen scheitern unterschiedlich

Server-Sent Events ist der deutlichste antwortseitige Fall: Vollständiges Puffern wird zur unendlichen Wartezeit. Die Anwendung muss auf jedem unterstützten Produktionspfad prüfen, ob Ereignisse im erwarteten Takt erscheinen, nicht nur ob Header angekommen sind.

Chunked Oblivious HTTP motiviert beide Richtungen. Der Client kann weiter senden, während der Server bereits antwortet. Beide Nachrichten brauchen ein eigenes Signal. Das IESG-Write-up bezeichnet das inkrementelle Feld als Abhängigkeit dieser Arbeit und berichtet zugleich von wenigen laufenden Implementierungen. Das ist ein Anlass zum Messen, nicht zur Abschwächung der Semantik.

RFC 10036 weist außerdem darauf hin, dass Extended CONNECT für bidirektionale Protokolle meist besser zur HTTP-Architektur passt. HTTP/2 und HTTP/3 definieren entsprechende Mechanismen für WebSockets. Eine gewöhnliche Anfrage-Antwort mit inkrementellem Inhalt sollte eine bewusste Kompatibilitätsentscheidung sein; ein Feld verwandelt nicht jede Proxy-Kette in einen Tunnel.

Die Beweiskette endet beim beobachteten Fortschritt

Der Sender verantwortet die auf der Nachricht erklärte Absicht. Jede Zwischenstelle verantwortet Unterstützung, Inspektionspolitik, Kapazitätsgrenze und Pufferfenster. Der Anwendungsverantwortliche entscheidet, ob der gemessene Pfad für das Produkt reicht und welcher Ausweichweg sicher ist.

Die Kette beginnt bei Nachrichtenidentität und -richtung, dem tatsächlich gelesenen booleschen Wert sowie Software und Konfiguration jedes Hops. Sie folgt Felderhalt, lokalem Modus, Byte- und Zeitgrenzen, Ein- und Ausgangszeiten, Ablehnungen und vertrauenswürdigen Proxy-Status-Angaben. Sie endet beim ersten Client-Ereignis, weiterem Takt, Anwendungszustand und Ressourcenwirkung.

Keine Ebene darf als Beleg für die nächste gelten. Ein registriertes Feld beweist keine Unterstützung. Unterstützung beweist nicht die Behandlung dieser Anfrage. Ausgang an einem Hop beweist keine Ende-zu-Ende-Zustellung. Das erste Byte beweist keinen sicheren Dauerbetrieb. Der Standard macht eine Entscheidung ausdrückbar; nur gepflegte Laufzeitevidenz zeigt, wohin die Bytes gelangten.

Quellen