Chunked Transfer Encoding

Chunked transfer encoding separates the transmission of an HTTP/1.1 message body from knowing its final length. A response using Transfer-Encoding: chunked carries a sequence of chunks, each containing a hexadecimal byte count followed by that many bytes, with carriage-return and line-feed delimiters. A zero-length chunk marks the end of the body, optionally followed by trailer fields. The sender must not also send Content-Length. HTTP libraries normally produce and decode this framing; application developers generally write body data rather than construct chunk headers manually.

The practical benefit is that a server can send useful output before completing all its work. For example, a foundation model might take several seconds to generate a complete answer. An application can consume incremental model output and immediately forward text updates to the user. This reduces perceived waiting time and time to first useful output, but does not necessarily reduce the model's total generation time. Streaming can also reduce buffering requirements, although slow consumers still require backpressure and bounded queues.

Transport chunks are not application messages. A chunk might contain part of a text token, several tokens, or portions of multiple events. Network reads can split or combine data differently again. Clients must use incremental character decoding and an application-level parser rather than assume that each read contains a complete JSON object or Unicode character. Server-sent events provide an event format over an HTTP response, commonly using the text/event-stream media type. They can use chunked transfer encoding over HTTP/1.1, but SSE and chunked encoding are not interchangeable terms. WebSockets instead provide a separate, bidirectional framed protocol and do not use HTTP chunked encoding for their messages.

In AWS, Amazon Bedrock operations such as ConverseStream and InvokeModelWithResponseStream return structured event streams for supported models. A backend consumes those events and translates relevant text deltas into an application protocol, such as SSE. Bedrock event-stream messages are not simply raw text chunks. Amazon API Gateway can expose streaming responses through supported REST API integrations when response streaming is configured. Choosing a gateway alone does not guarantee streaming: API type, integration type, transfer mode, timeouts, and intermediary buffering must all be checked. A WebSocket API is an alternative when the interaction requires ongoing bidirectional messages, rather than one progressively delivered HTTP response.

Streaming must work across the entire request path. A function or container may flush output promptly while a reverse proxy, compression layer, or client library buffers it. Test the actual deployed path using timestamps for first byte, first meaningful text, and completion. Chunked encoding is specific to HTTP/1.1; HTTP/2 and HTTP/3 support incremental delivery using their own data framing rather than Transfer-Encoding: chunked. A gateway can therefore translate framing between connections without changing the application's streaming behavior.

Operationally, smaller writes improve responsiveness but increase processing and framing overhead; modest batching can provide a better balance. Configure idle and overall timeouts, handle client cancellation, and stop upstream generation when possible. Once response headers have been sent, an application cannot replace the HTTP status with a later error, so define explicit application-level completion and error events. Treat premature disconnection as potentially incomplete output, and avoid automatically replaying requests that could duplicate tool actions or charges. For AI systems, also decide whether generated text needs moderation before release: content already streamed to a user cannot be reliably withdrawn.