Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incremental tweaks #3007

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 32 additions & 13 deletions draft-ietf-httpbis-incremental.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,25 +60,24 @@ 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.
request-response pair could create what is, in effect, a bi-directional
communication channel.

However, these applications are fragile when HTTP intermediaries are involved.
Applications that rely on incremental delivery of messages 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 Server-Sent Events, an intermediary tries to buffer the HTTP
response completely before forwarding it could be left waiting indefinitely.
A client might never receive any portion of the 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.
In the case of requests that involve any bi-directional exchange,
an intermediary that tries to buffer entire messages --
either request or response -- prevents any data from being delivered.

To help avoid such behavior, this document specifies the "Incremental" HTTP header
field, which instructs HTTP intermediaries to begin forwarding the HTTP message
Expand Down Expand Up @@ -123,8 +122,6 @@ 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
Expand All @@ -141,10 +138,32 @@ 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}}).

For performance and efficiency reasons, a small amount of buffering might be used
by intermediaries, even for incremental messages. Immediate forwarding might be
exploited to cause an intermediary to waste effort on many small packets.
Enabling incremental delivery might instead set limits on the number bytes
that are buffered or the time that buffers are held before forwarding.


# IANA Considerations

TBD
An HTTP field named Incremental is registered
in the Hypertext Transfer Protocol (HTTP) Field Name Registry,
following the procedures in {{Section 18.4 of !HTTP=RFC9110}}.
The following values are registered:

Field Name:
: Incremental

Status:
: permanent

Reference:
: this document

Comments:
: (none)
{: spacing="compact"}

--- back

Expand Down