From fab334020a3dec84b97279309868ba306c160b0e Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 17 Feb 2025 12:03:22 +1100 Subject: [PATCH 1/3] Add incremental draft --- draft-ietf-httpbis-incremental.md | 154 ++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 draft-ietf-httpbis-incremental.md diff --git a/draft-ietf-httpbis-incremental.md b/draft-ietf-httpbis-incremental.md new file mode 100644 index 000000000..87153a8d1 --- /dev/null +++ b/draft-ietf-httpbis-incremental.md @@ -0,0 +1,154 @@ +--- +title: "Incremental HTTP Messages" +docname: draft-ietf-httpbis-incremental-latest +category: std +wg: httpbis +ipr: trust200902 +keyword: internet-draft +stand_alone: yes +pi: [toc, sortrefs, symrefs] +author: + - + fullname: + :: 奥 一穂 + ascii: Kazuho Oku + org: Fastly + email: kazuhooku@gmail.com + - + fullname: Tommy Pauly + organization: Apple + email: tpauly@apple.com + - + fullname: Martin Thomson + organization: Mozilla + email: mt@lowentropy.net + +normative: + +informative: + PROXY-STATUS: RFC9209 + SSE: + target: https://html.spec.whatwg.org/multipage/server-sent-events.html + title: Server-Sent Events + author: + - + org: WHATWG + + + +--- abstract + +This document specifies the "Incremental" HTTP header field, which instructs +HTTP intermediaries to forward the HTTP message incrementally. + + +--- middle + +# Introduction + +HTTP {{!HTTP=RFC9110}} permits receivers to begin processing portions of HTTP +messages as they arrive, rather than requiring them to wait for the entire HTTP +message to be received before acting. + +Some applications are specifically designed to take advantage of this +capability. + +For example, Server-Sent Events {{SSE}} uses a long-running HTTP response, where +the server continually sends notifications as they become available. + +In the case of Chunked Oblivious HTTP Messages +{{?CHUNKED-OHTTP=I-D.ietf-ohai-chunked-ohttp}}, the client opens an HTTP request +and incrementally sends application messages, while the server can start responding +even before the HTTP request is fully complete. In this way, the HTTP +request-response pair effectively serves as a bi-directional communication +channel. + +However, these applications are fragile when HTTP intermediaries are involved. +This is because HTTP intermediaries are not only permitted but are frequently +deployed to buffer complete HTTP messages before forwarding them downstream +({{Section 7.6 of HTTP}}). + +If such a buffering HTTP intermediary exists between the client and the server, +these applications may fail to function as intended. + +In the case of Server-Sent Events, when an intermediary tries to buffer the HTTP +response completely before forwarding it, the client might time out before +receiving any portion of the HTTP response. + +In the case of Chunked Oblivious HTTP Messages, when an intermediary tries to +buffer the entire HTTP request, the client will not start receiving application +messages from the server until the client closes the request, effectively +disrupting the intended incremental processing of the request. + +To help avoid such behavior, this document specifies the "Incremental" HTTP header +field, which instructs HTTP intermediaries to begin forwarding the HTTP message +downstream before receiving the complete message. + + +# Conventions and Definitions + +{::boilerplate bcp14-tagged} + +The term Boolean is imported from {{!STRUCTURED-FIELDS=RFC8941}}. + + +# The Incremental Header Field + +The Incremental HTTP header field expresses the sender's intent for HTTP +intermediaries to start forwarding the message downstream before the entire +message is received. + +This header field has just one valid value of type Boolean: "?1". + +~~~ +Incremental = ?1 +~~~ + +Upon receiving a header section that includes the Incremental header field, HTTP +intermediaries SHOULD NOT buffer the entire message before forwarding it. +Instead, intermediaries SHOULD transmit the header section downstream and +continuously forward the bytes of the message body as they arrive. + +The Incremental HTTP header field applies to each HTTP message. Therefore, if +both the HTTP request and response need to be forwarded incrementally, the +Incremental HTTP header field MUST be set for both the HTTP request and the +response. + +The Incremental field is advisory. Intermediaries that are unaware of the field +or that do not support the field might buffer messages, even when explicitly +requested otherwise. Clients and servers therefore cannot expect all +intermediaries to understand and respect a request to deliver messages +incrementally. Clients can rely on prior knowledge or probe for support on +individual resources. + +# Security Considerations + +## Applying Concurrency Limits + +To conserve resources required to handle HTTP requests or connections, it is +common for intermediaries to impose limits on the maximum number of concurrent +HTTP requests that they forward, while buffering requests that exceed this +limit. + +Such intermediaries could apply a more restrictive concurrency limit to requests +marked as incremental to ensure that capacity remains available for +non-incremental requests, even when the maximum number of incremental requests +is reached. This approach helps balance the processing of different types of +requests and maintains service availability across all requests. + +When rejecting incremental requests due to reaching the concurrency limit, +intermediaries SHOULD respond with a 503 Service Unavailable error, accompanied +by a connection_limit_reached Proxy-Status response header field +({{Section 2.3.12 of PROXY-STATUS}}). + + +# IANA Considerations + +TBD + +--- back + +# Acknowledgments +{:numbered="false"} + +TODO acknowledge. From f0a2a2a418003dfd8e96426f46ba09e2b633789c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 17 Feb 2025 12:03:25 +1100 Subject: [PATCH 2/3] Automatic update of .gitignore --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 78203b916..1508c2f2b 100644 --- a/.gitignore +++ b/.gitignore @@ -26,6 +26,7 @@ draft-ietf-httpbis-client-cert-field.xml draft-ietf-httpbis-compression-dictionary.xml draft-ietf-httpbis-connect-tcp.xml draft-ietf-httpbis-digest-headers.xml +draft-ietf-httpbis-incremental.xml draft-ietf-httpbis-message-signatures.xml draft-ietf-httpbis-no-vary-search.xml draft-ietf-httpbis-optimistic-upgrade.xml From 11e82234351fc1018130dd3e169783ec5ff47237 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 17 Feb 2025 12:03:25 +1100 Subject: [PATCH 3/3] Automatic update of .github/CODEOWNERS --- .github/CODEOWNERS | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 13f760a12..5618673d4 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -3,6 +3,7 @@ draft-ietf-httpbis-cache-groups.md mnot@mnot.net draft-ietf-httpbis-compression-dictionary.md pmeenan@google.com yoav.weiss@shopify.com draft-ietf-httpbis-connect-tcp.md ietf@bemasc.net +draft-ietf-httpbis-incremental.md kazuhooku@gmail.com tpauly@apple.com mt@lowentropy.net draft-ietf-httpbis-no-vary-search.md d@domenic.me jbroman@chromium.org draft-ietf-httpbis-optimistic-upgrade.md ietf@bemasc.net draft-ietf-httpbis-resumable-upload.md marius@transloadit.com guoye_zhang@apple.com lucas@lucaspardue.com