Field name ... or maybe just semantics too

[martinthomson]

A name of "request-streaming" implies that this only applies to requests. That's not really necessary. I think that it would be helpful to have this be more general. This can be a per-message basis.

I would suggest "Stream-Body" or "Incr[emental]-Delivery" or even just "Incremental". This is a signal from the sender of that message to any intermediary that incremental delivery of this message would be optimal. Importantly, a request can't speak about a response.

[martinthomson]

Or "Incr[emental]-Forwarding" or "Forward-Incr" so that it is about forwarding expectations.

[kazuho]

Thank you for starting the discussion.

A name of "request-streaming" implies that this only applies to requests.

This I agree with. To fix the issue, I think it might be a good idea to include the term "bidirectional," due to the following reasons:

• I think people think that HTTP response is streamed (because browsers render incrementally!).
• The only case that we have this problem is when applications want streaming in both directions - blocking intermediaries work perfectly fine if only the request (or the response) is streamed.

Separately, I think we'd prefer having a name that adequately acquires the attention of HTTP application developers when they:

• try to create applications that do bi-directional streaming, or
• when they hit issues by doing that.

Due to the first bullet point, I'm somewhat negative to having something like "Forwarding" in the title, even though such title might be technically correct.

I think we want the streaming header to be set by any application that needs bi-directional streaming, regardless of intermediaries being involved in their deployments. That is because we do not want to see those applications break when they add buffering intermediaries.

To paraphrase, setting the streaming header always would be the way to adhere to the HTTP semantics for those applications.

So, I think my preference goes to something like "Bidirectional Streaming of HTTP Bodies". WDYT?

[martinthomson]

So I don't think that bidirectional is the important property. After all, if the request is buffered and the response is not, you don't have full duplex (or bidirectional) communication. That is something you might get with server sent events, which this would make far more reliable overall (if intermediaries supported the signaling, that is, independent of any preexisting arrangements that have been setup, which I know is common for existing uses of SSE).

The key property is that data is forwarded as it arrives at an intermediary, not buffered. Unbuffered might be a negative framing of this that works (even if I don't ordinarily like using negative names).

The fact that two unbuffered messages can be assembled to form voltron^wa bidirectional protocol is interesting, but not an essential property.

I also don't think that you can assume that an unbuffered request naturally leads to an unbuffered response. It could in a great many cases (100-continue is a good example of that, especially with OHTTP). But not all. Incremental processing is often valuable for large bodies, such that buffering is a performance hazard.

So, for me at least, bidirectional communication should feature prominently in the rationale, but it should not be how the feature is defined. It should just be a consequence of one of the ways that the feature is used.

[kazuho]

FWIW my point has been that a client or a server cannot tell if an intermediary is buffering in either direction, unless they try to use HTTP request-response as a bi-directional channel.

But I can see some might argue otherwise if they take out-of-band knowledge into consideration.

To that end, I do not have a strong reason to object against the idea of changing the header field to indicate how the HTTP message is delivered in each direction.

[martinthomson]

Thanks @kazuho. The only question I have then is whether it is useful for the client to be able to signal as part of a request whether it wants the response to be streamed.

I suspect that the answer there is that the server will know that a response should be streamed and mark the response properly. I'm trying to think of cases where that wouldn't be true and not finding any.

[kazuho]

@martinthomson

The only question I have then is whether it is useful for the client to be able to signal as part of a request whether it wants the response to be streamed.

I suspect that the answer there is that the server will know that a response should be streamed and mark the response properly. I'm trying to think of cases where that wouldn't be true and not finding any.

+1 to not giving client also control.

FWIW, in case of newly written applications, server developers would have the opportunity to set the flag. In contrast, having such a feature would be helpful to existing applications that need bi-directional streaming, as one would need to change only one side.

Some people might argue (or presume) that such a flag would be useful for clients that can process the response incrementally. Consider a MP3 player. It would always be helpful for them to receive response incrementally, as the playback can start earlier.

But the fact is that we do not want to start such a arms race, where everybody starts setting the flag, as then, proxies become unable to respect the flag.

To conclude, I think we should be clear that the flag is specifically for protocols that break if the intermediaries buffer the HTTP message. That flag changes the policy of intermediaries from "forward-now-or-buffer" to "forward-now-or-fail" (though I'm not sure how intermediaries can fail if they see the flag attached to the response).