What is more_body with HTTP response?

Question

With the ASGI framework Starlette, it has a streaming response that makes use of some more_body parameter in the HTTP response to denote if chunks have finished streaming (source code). There is an article from Starlette talking about this: Working with ASGI and HTTP.

Is this more_body technique a standard design pattern using HTTP, like Server Sent Events (SSE), or is it something specific to Starlette?

Answer 1

The more_body parameter used in Starlette's streaming response is not a standard HTTP feature, but a part of ASGI (Asynchronous Server Gateway Interface) specifications. It is specific to asynchronous Python web frameworks like Starlette that use ASGI.

more_body (bool) – Signifies if there is additional content to come (as part of a Request message).

• If True, the consuming application should wait until it gets a chunk with this set to False.
• If False, the request is complete and should be processed. Optional; if missing defaults to False.

In the context of ASGI and Starlette, more_body is used to indicate whether the response is complete or if more data is expected. When a response is being streamed, setting more_body to True tells the ASGI server that more data chunks are forthcoming. Once the entire response has been sent, more_body should be set to False, signaling the end of the response.

That mechanism is different from standard HTTP features like Server-Sent Events (SSE). SSE is a standard that allows servers to push updates to clients over a single, long-lived HTTP connection. In contrast, the more_body approach is an ASGI-specific way to manage streaming responses within the framework's asynchronous processing model.

Answer 2

Here I tried to prepare a comprehensive comparison as a table between SSE and the more_body flag plus websocket which is a close pattern to those techniques:

Feature	HTTP Response Streaming (more_body)	WebSockets	Server-Sent Events (SSE)
Use Case	Streaming large files or data	Real-time, bidirectional messaging	Real-time updates from server to client
Direction	Unidirectional (server → client)	Bidirectional (server ↔ client)	Unidirectional (server → client)
Connection Type	Single HTTP response	Persistent connection	Persistent connection
Protocol	HTTP/1.1 or HTTP/2	ws:// or wss://	HTTP/1.1 or HTTP/2
Data Flow	Streamed in chunks	Independent messages	Event-driven messages
Message Format	Arbitrary data (binary or text)	Framed messages (binary or text)	Text-based event stream
Browser Support	Universal	Universal (with possible polyfills)	Universal (with possible polyfills)
Persistent Connection	No (but stream can be long-lived)	Yes	Yes
Complexity	Low	Medium	Low
Overhead	Low (standard HTTP)	Low (after handshake)	Low (standard HTTP)

---

It is worth noting that there are some other technologies and approaches for communication on the web namely Long Polling, WebRTC, and GraphQL Subscriptions, to name a few.