Hlavička Incremental říká prostředníkům, ať HTTP zprávu posílají dál po částech

Prohlížeč málokdy mluví se serverem přímo. Mezi nimi stojí prostředníci, tedy proxy servery ve firemní síti, brány poskytovatele nebo uzly sítě CDN. Norma HTTP Semantics jim dovoluje počkat si na celou zprávu a teprve pak ji poslat dál, a řada z nich to tak dělá.

U běžné stránky je to jedno. U aplikace, která data posílá průběžně, to znamená konec provozu. Právě na to míří RFC 10036, které pracovní skupina httpbis dotáhla do stavu navržené normy a IETF vydal v srpnu 2026. Napsali ho Kazuho Oku z Fastly, Tommy Pauly z Applu a Martin Thomson z Mozilly.

Prostředník, který čeká na tečku

Norma jmenuje dva případy. Prvním jsou Server-Sent Events, kde server drží jedinou dlouhou odpověď a posílá do ní oznámení, jak vznikají. Prostředník, který si takovou odpověď chce nejdřív uložit celou, čeká na její konec libovolně dlouho a klient se nedozví vůbec nic.

Druhým je návrh Chunked Oblivious HTTP Messages z února 2026. Klient v něm otevře požadavek a data do něj dosílá postupně, zatímco server může začít odpovídat dřív, než požadavek skončí. Z dvojice požadavek a odpověď se tak stane obousměrný kanál a prostředník, který si počká na celek, zastaví oba směry naráz.

Jedna hlavička, dvě hodnoty

Hlavička Incremental je strukturované pole typu Item podle RFC 9651, tedy jedna hodnota bez seznamu a bez slovníku. Platná je jen pravdivostní: ?1 znamená „posílej dál průběžně“, ?0 obvyklé chování. Cokoli jiného příjemce ignoruje.

Incremental: ?1

Pole se vztahuje na jednu zprávu, ne na dvojici. Když má průběžně téct požadavek i odpověď, musí ho mít obojí zvlášť. Prostředník, který u pravdivé hodnoty vyhoví, pošle dolů hlavičkovou část a pak předává bajty obsahu tak, jak přicházejí; hlavičky a přípony si přitom smí uložit celé, protože hlavička mluví o obsahu zprávy, ne o nich.

Zajímavá je i opačná hodnota. ?0 nic nemění, jenže výslovný signál dá prostředníkovi větší jistotu, že si zprávu uložit může. A žádost neplatí jen pro proxy: knihovna nebo rozhraní, které průběžný přenos obsahu neumí, má podle normy použít přítomnost hlavičky aspoň k tomu, aby ukládání omezila.

Odmítnout se smí, mlčky čekat ne

Tohle je na normě to podstatné. Když prostředník průběžné přeposlání odmítne, musí vrátit chybu, ne se tiše vrátit k ukládání celé zprávy. Klient se tak o problému dozví hned místo toho, aby čekal na odpověď, která nepřijde.

• Prostředník, který obsah zpráv prohlíží a pouští dál jen to, co uzná za bezpečné, potřebuje vidět celek. Odmítá natrvalo a má odpovědět kódem 501 s hlavičkou Proxy-Status podle RFC 9209 a chybou incremental_refused.
• Prostředník, kterému došla kapacita souběžných požadavků, odmítá dočasně kódem 429 a chybou connection_limit_reached. Norma počítá s tím, že si na průběžné požadavky nastaví přísnější strop než na ostatní, aby mu kvůli nim nedošla obsluha pro zbytek provozu.

Trochu ukládat se přitom smí dál. Okamžité posílání se dá zneužít k tomu, aby prostředník rozmělnil práci do spousty drobných paketů, takže si smí nastavit mez v bajtech nebo v čase. Držet data neomezeně ale nesmí: jakmile padne kterákoli z těch dvou mezí, jde obsah ven.

Záruka to není

Prostředník, který hlavičku nezná, si jí nevšimne a chová se jako dřív. Klient, jehož aplikace na průběžném doručování stojí, se proto podle normy musí spolehnout na to, co o cestě ví předem, nebo si podporu u konkrétního zdroje vyzkoušet.

Autoři k tomu sami dodávají výhradu, která se v takových dokumentech čte málokdy: kdo staví nad HTTP obousměrný protokol, udělá obvykle lépe, když sáhne po rozšířeném CONNECT (RFC 8441 pro HTTP/2, RFC 9220 pro HTTP/3). Ten do architektury HTTP zapadá líp.

Dosud si každý pomáhal po svém

Vyrovnávací paměť prostředníka se doteď vypínala lokálně. V nginxu je na to direktiva proxy_buffering a hlavička X-Accel-Buffering s hodnotami yes a no, kterou pošle server za proxy; správce ji navíc může nechat ignorovat. Funguje ale jen v nginxu a jen na odpovědi. Hlavička z RFC 10036 je proti tomu jedna žádost pro celý řetěz a platí i na požadavek.

IANA má obojí zapsané. V rejstříku jmen hlaviček HTTP stojí Incremental jako trvalé pole typu Item, v rejstříku chyb Proxy-Status pak incremental_refused s doporučeným kódem 501.

Práce na dokumentu trvala rok a čtyři měsíce: první verzi návrhu skupina zveřejnila 29. dubna 2025, poslední 2. března 2026. Jestli z toho něco bude, se pozná až podle toho, kolik proxy serverů hlavičku začne číst.

Zdroje

• RFC 10036: Incremental Forwarding of HTTP Messages, RFC Editor
• Záznam dokumentu v IETF Datatrackeru (dřívější draft-ietf-httpbis-incremental)
• Hypertext Transfer Protocol (HTTP) Field Name Registry a HTTP Proxy Error Types, IANA
• Dokumentace modulu ngx_http_proxy_module, nginx