Zusammenfassung

  • Incremental: ?1 bittet Intermediäre für eine einzelne HTTP-Nachricht, Inhalt weiterzuleiten, bevor die ganze Nachricht eingegangen ist. Anfrage und Antwort sind getrennte Nachrichten und benötigen das Feld jeweils selbst.
  • Versteht ein Hop das Feld und lehnt die inkrementelle Body-Weiterleitung grundsätzlich ab, muss er einen Fehler erzeugen, statt alles still zu puffern. Sicherheitsbedingte Unvereinbarkeit wird mit 501 und incremental_refused, temporärer Auslastungsdruck mit 429 und connection_limit_reached beschrieben.
  • Das Feld garantiert keinen durchgängigen Datenstrom. Unwissende oder nicht unterstützende Hops dürfen puffern, unterstützende Hops begrenzte Zeit-/Byte-Puffer verwenden. Der Beleg muss Richtung, Hop-Erkennung, Richtlinie, Schwellenwerte, Fehlerkontext und gemessene Latenz verbinden.

Besonders sichtbar wird das Problem bei einer bidirektionalen Anwendung. Der Client sendet weiter, der Server kann schon früh antworten, doch ein Proxy wartet auf die vollständige Anfrage oder Antwort. Beide Enden bleiben aktiv und erhalten dennoch nicht die Daten, die den nächsten Schritt auslösen würden.

RFC 10036, Incremental Forwarding of HTTP Messages, erschien im August 2026 als vorgeschlagener IETF-Standard. Autoren sind Kazuho Oku, Tommy Pauly und Martin Thomson. Das am 31. August gespeicherte IETF-Profil nennt für Oku vier RFCs. Fastlys eigene Autorenseite beschreibt ihn als Principal OSS Engineer sowie Autor von H2O, quicly und picoTLS. Das belegt langjährige Arbeit an leistungsfähiger Internetsoftware, aber weder Alleinerfindung noch Kontrolle über Implementierungen.

Eine Absicht gilt für genau eine Nachricht

Incremental ist ein Structured-Fields-Item; nur Boolean ist gültig, ein anderer Typ wird ignoriert. ?1 fordert schrittweise Weiterleitung an, ?0 beschreibt den Normalfall, in dem ein Intermediär die gesamte Nachricht puffern kann.

Das Feld gehört nicht zur Verbindung. Eine markierte Anfrage markiert die Antwort nicht. Braucht eine Anwendung beide Richtungen, muss das Feld in beiden Nachrichten stehen. Eine pauschale Aussage „dieser Endpunkt streamt“ ist ohne Angabe der Richtung daher wertlos.

Ein unterstützender Intermediär sollte den Headerabschnitt weitergeben und eintreffende Inhaltsbytes kontinuierlich senden. Header und Trailer dürfen vollständig gepuffert werden. Für echte bidirektionale Protokolle nennt die RFC Extended CONNECT als im Allgemeinen besser zur HTTP-Architektur passend. Das Feld ersetzt keine Protokollentscheidung.

Eine bewusste Ablehnung darf nicht wie Erfolg aussehen

Entscheidet sich ein Intermediär, der das Feld versteht, klar gegen inkrementelle Body-Weiterleitung, muss er mit einem Fehler antworten. Eine spätere Komplettzustellung erfüllt die geforderte Zeiteigenschaft nicht.

Auf einen Fehler kann die Anwendung reagieren: Route oder Protokoll wechseln, Funktion begrenzen, später wiederholen oder Nichtverfügbarkeit anzeigen. Stilles Puffern lässt die Transaktion gesund erscheinen, während Konsole, Ereignisstrom oder Frühantwort unbrauchbar werden.

Nicht jede Verzögerung ist damit eine Ablehnung. Auch sofortiges Senden jedes kleinsten Fragments wird nicht verlangt. Sichtbar wird eine konkrete Richtlinienentscheidung eines teilnehmenden Hops. Running-Code Primacy verlangt deshalb Versuche über den realen Pfad: erkennbare Chunks, Empfangs- und Weiterleitungszeitpunkte, provozierte Ablehnung und Prüfung, ob der Proxy-Kontext sein Ziel erreicht.

Dauerhafte Inspektionsgrenze oder temporärer Engpass

Manche Intermediäre müssen den gesamten Body sehen, bevor sie ihn als sicher einstufen. Diese Funktion ist mit inkrementeller Zustellung unvereinbar. RFC 10036 empfiehlt 501 Not Implemented plus incremental_refused in Proxy-Status. Ohne Änderung von Inspektion, Route, Ressource oder Protokoll wird eine Wiederholung kaum helfen.

Anders ist die Kapazitätsgrenze. Inkrementelle Vorgänge können Ressourcen lange belegen. Ein Hop darf dafür einen strengeren Konkurrenzpool nutzen und gewöhnliche Anfragen schützen. Bei ausgeschöpftem Pool empfiehlt die RFC 429 Too Many Requests mit connection_limit_reached.

Hier kann die Ressource kompatibel sein, nur ein Platz fehlt. Backoff, Zulassung, Priorität und Kapazität sind die richtigen Hebel. Beide Fälle als „Streaming kaputt“ zusammenzufassen, entfernt den entscheidenden Unterschied.

Der Statuscode allein genügt nicht. 501 und 429 haben andere Bedeutungen. Proxy-Status, verantwortlicher Hop, Ressource, Richtlinienversion und Zeit gehören zusammen. Nicht teilnehmende Hops bleiben als Lücke erhalten.

Der unbekannte Hop kann weiter schweigen

Ein Intermediär, der das Feld nicht kennt, ändert sein Verhalten nicht. Auch ein nicht unterstützender Hop kann puffern. Fehlende Fehler sind deshalb kein Beweis für Ende-zu-Ende-Unterstützung.

Der unterstützende Hop, der ablehnt, ist paradoxerweise transparenter als der unwissende Hop, der verzögert und weiterleitet. Getestetes Vorwissen kann auf kontrollierten Pfaden helfen; sonst empfiehlt die RFC Probes einzelner Ressourcen.

Die Ressource ist die richtige Einheit. Pfad, Region, Bodytyp, Kundenklasse und Last können Richtlinien ändern. Ein erfolgreicher Test gilt für seine Bedingungen und ist kein dauerhaftes Zertifikat einer Marke.

Die Agency-Grenze bleibt verteilt: Der Sender äußert Absicht; jeder Intermediär entscheidet über Sicherheit, Kapazität und Weiterleitung; der Endpunkt deutet das Ergebnis. Niemand kann für nicht kontrollierte Software versprechen.

Begrenztes Puffern kann das Ziel trotzdem verfehlen

Auch ein unterstützender Hop darf kleine Mengen sammeln, um Effizienz zu sichern und Missbrauch mit winzigen Paketen zu begrenzen. Zeit- oder Bytegrenzen sind möglich. Bei Erreichen einer Grenze muss weitergeleitet werden; unbegrenztes Halten ist ausgeschlossen.

„Unterstützt“ bedeutet damit nicht „erfüllt das Latenzbudget“. Eine Bytegrenze ist bei großen Antworten unsichtbar und bei seltenen Ereignissen schädlich. Ein kurzer Timer für Menschen kann für Maschinen zu lang sein.

Schwellenwerte, Dienstklasse und Auslastung brauchen Versionen und müssen mit der Zeit bis zum ersten Byte verbunden werden. Der Standard liefert die Minimum Initial Specification; Ressourcenauswahl, Inspektion, Kapazität, SLO und Fallback bleiben lokal.

Den Pfad-zum-Ergebnis-Beleg bauen

Erfassen Sie Client, Server, Ressource, Build, Nachrichten-ID und Richtung. Bewahren Sie Feldwert, Boolean-Prüfung, setzende Komponente und Anwendungszweck. Für jeden kontrollierten oder teilnehmenden Intermediär gehören Protokollsegment, Erkennung, Inspektionsregel, Body-/Header-/Trailer-Politik, Zeit-/Bytegrenze, Konkurrenzpool, Belegung und Priorität in den Datensatz.

Verbinden Sie HTTP-Status, Proxy-Status-Mitglied, Fehlertyp, verantwortlichen Hop sowie Empfangs- und Weiterleitungszeit von erstem und letztem Byte. Unterscheiden Sie akzeptable inkrementelle Zustellung, begrenzte Pufferdegradation, strukturelle Ablehnung, temporäre Ablehnung, mutmaßlich stilles Puffern und unzureichende Evidenz.

Danach folgt die Entscheidung mit Eigentümer: neue Route, anderes Protokoll, Wiederholung, Kapazität, Sicherheitsausnahme, reduzierter Modus und Termin. Sensible Bodies müssen dafür nicht gespeichert werden; sichere Korrelationskennungen, Richtlinienversionen und Zeitstempel reichen oft.

Ein unbekannter Hop oder entfernter Proxy-Status bleibt unbekannt. Genau diese sichtbare Unsicherheit verhindert, dass ein kleines Feld zu einer erfundenen Garantie wird.

Quellen