Re: Mohamed Boucadair's No Objection on draft-ietf-httpbis-incremental-03: (with COMMENT)

On Mon, Feb 2, 2026, at 23:37, Mohamed Boucadair via Datatracker wrote:
> # Advisory
[...]
> ## How such function is operationally justified for intermediary nodes? What is
> the incentive to deploy here?

By the same justification as the deployment itself is justified: to better serve the interests of the server (or client) that the intermediary exists to help.  For instance, if a CDN wants to be more useful to a website that contracts with them, they might consider this header field.

> ## How sending the error makes things better for applications?

The error code allows applications to identify when this specific condition is the cause of a problem.  If that is relevant to their handling of error conditions, they can use that information.  Or not, because, like many such HTTP errors, generic handling of errors is possible.

> ## How applications are expected to behave when they receive such errors?

As they would with any error of the same class.  HTTP has to be pretty non-specific about these things, because the range of applications that use HTTP is very diverse.  So while some would just retry, others might show an error to an operator, but others might use a different recovery path.

> # Exceptions
[...]
> ## Shouldn’t all these exceptions be reminded in this document as well?

No.  They are not exhaustive reasons in RFC 9110.  More to the point, the goal here is to give endpoints (client/origin server) a way to suggest that whatever reasons might exist for buffering, they would like the intermediary to set those aside.  Whether it does it up to the intermediary, of course.

> ## Isn’t “SHOULD”/”SHOULD NOT” recommendation betting that the message is safe
> to forward by default?

What do you mean by "safe"?  In the HTTP protocol, it is always safe to forward messages one byte at a time.  Policy at intermediaries might lead to situations where they accept incremental forwarding, or not.  Whether the input from clients or origin servers can affect that policy is a matter for policy also.  Some notion of "safety" might be a factor in setting that policy, but we can't really speculate on that point.

> ## BTW, it would be helpful to add a forward reference to Section 4.

It's a small enough document that saying "look at the next section" seems unnecessary in this case.

> # HTTP implementations
>
> CURRENT:
>    The request to use incremental forwarding ** also ** applies to HTTP
>    implementations.
>
> I don’t understand “also” mention and “HTTP implementations” mentioned here.

The HTTP client an application uses can buffer messages between the application and the network.  They often do, for performance reasons, if nothing else.  If you continue the quote, I thought it was clear this was talking about APIs.

> Isn’t the signal only targeting intermediaries per the following?
>
> CURRENT:
>    A true value ("?1") indicates that the sender requests intermediaries
>    to forward the message incrementally, as described below.

An HTTP implementation is often an intermediary, at least as far as this specification goes.  Which is why the "also".

> # Misc.
>
> ## SSE Example
>
> CURRENT:
>    For example, Server-Sent Events [SSE] uses a long-running HTTP
>    response, where the server continually sends notifications as they
>    become available.
>
> Is the assumption here that only portions of a notification are sent, not that
> a full notification is included in a message?
>
> Otherwise, I don’t understand how this is used as an example.

SSE sends a series of notifications in the body of a single HTTP message.  If the entire message is buffered, then the first and last notification arrive at the same time, which is probably not what was intended by the sender.  Hence the suggestion that Incremental: ?1 is worth using with SSE.  That's all.  This doesn't really say anything about individual parts of messages.

> ## Probing
>
> CURRENT:
>    Clients can rely on
>    prior knowledge or probe for support on individual resources.
>
> ### Are there pointers to examples of how such probe can be done?

No.  That's best left as an exercise for the reader.

> ### I wonder to what extent the results of such probing are reliable given that
> rate-limit (or filters to decide which messages can be granted incremental
> forwarding) may be in place.

Yes.  Hence the desire to avoid implying that a particular method is "good" for probing.

Received on Tuesday, 3 February 2026 01:17:47 UTC