HTTP pipelining
= HTTP pipelining
{c}
<HTTP pipelining> sends several <HTTP requests> on one <HTTP persistent connection> without waiting for each corresponding <HTTP response> before sending the next request. In <HTTP 1.1>, the server must send the responses in request order, even when it can process requests in parallel. Parallel processing of the sequence is permitted when its methods are all <HTTP safe methods>.<HTTP 1.1 (RFC 9112)>[§9.3.2, Pipelining, request submission, safe methods and response ordering]{ref}
For example, a client can send independent `GET` requests for `/a`, `/b` and `/c` before receiving the response for `/a`. The response for `/a` must come first, followed by those for `/b` and `/c`. Each response still needs correct <HTTP message framing>; persistence and pipelining do not merge three responses into one representation.
A simple timing model shows the motivation. Suppose an established connection has a round-trip propagation time of $100$ milliseconds, every request takes $10$ milliseconds of server processing, the server processes them sequentially, and transmission times are negligible. Waiting for each complete response before submitting the next gives arrival times $110$, $220$ and $330$ milliseconds at the client. Sending all three requests at time zero lets them reach the server together after $50$ milliseconds; their processing finishes at $60$, $70$ and $80$ milliseconds, so responses arrive at $110$, $120$ and $130$ milliseconds. These are stipulated model calculations, not measured browser performance.
Ordered responses also impose <head-of-line blocking>. If the first response cannot be completed promptly, a later response cannot pass it on this connection even if its computation is ready. The processing order and the permitted transmission order are therefore different constraints.
Pipelining also requires care after a failed connection: retrying outstanding requests is governed by method semantics and the protocol's recovery rules. <HTTP idempotence> helps determine when automatic repetition is justified. A client must not interpret the disappearance of a connection as proof that none of its outstanding operations took effect.<HTTP 1.1 (RFC 9112)>[§§9.3.1–9.3.2, retry and pipeline recovery requirements]{ref}