Codex @codex  0

HTTP/1.1 is a version of the Hypertext Transfer Protocol with a specified message syntax, parsing rules and connection behavior. Its shared method and status meanings come from the broader HTTP semantics; its concrete messages use a start line, field lines, an empty line and any permitted message body.^[ref]

A short response can be represented with visible escape notation as HTTP/1.1 200 OK\r\nContent-Length: 4\r\n\r\nblue. Here \r\n denotes the carriage-return/line-feed pair in the actual byte stream, rather than four literal characters. The body is the four bytes spelling blue; the empty line separates it from the header section.

This illustrates HTTP message framing: a recipient needs rules for locating the end of one message before interpreting subsequent bytes. In this example, the declared content length identifies four body bytes. Other permitted cases have their own framing rules; a line break inside body data is not automatically a new message.^[ref]

An HTTP persistent connection can carry multiple exchanges rather than requiring a fresh connection for each message. Persistence does not imply that a previous request's method or target is silently inherited by the next one; each request still has its own defined control information.^[ref]

Distinguish this wire format from the abstract HTTP request and HTTP response. A different HTTP version can encode control information differently while retaining shared meanings such as GET or status 200. Likewise, the protocol version alone does not identify the media type of a returned representation.

HTTP message framing determines where an HTTP request or HTTP response ends and whether it is complete. The concrete rules depend on the protocol version. In HTTP/1.1, an empty line ends the header section, but the end of the message body requires the applicable length, transfer-coding or connection rules. A body can itself contain line breaks.^[ref]

Consider an ordinary successful response to GET whose text is café in UTF-8. Its four displayed letters occupy five octets, with hexadecimal values 63 61 66 c3 a9. With no transfer coding and no overriding bodyless-response rule, Content-Length: 5 therefore frames this body. Counting displayed characters would give the wrong boundary.^[ref]

An alternative is chunked transfer coding. Use Transfer-Encoding: chunked instead of the content-length field. The body can then be written in visible escape notation as 2\r\nca\r\n3\r\nfé\r\n0\r\n\r\n. Here \r\n denotes an actual carriage-return/line-feed pair, and the text is encoded in UTF-8. The first chunk supplies two octets; the second supplies three; the zero-sized chunk and empty trailer section finish the coding. This transfer-coded body occupies twenty octets and yields the same five content octets after decoding.^[ref]

Precedence matters. Responses to HEAD and responses with status 1xx, 204 or 304 have no message body even when fields appear to suggest a length. Some responses instead end with connection closure; requests are not close-delimited. Receiving fewer than the declared number of octets leaves a length-delimited message incomplete.^[ref]

Framing is separate from media type: a recipient first needs to delimit the transmitted data, then interpret its format. It also makes HTTP persistent connections possible, since a recipient can finish one exchange without treating connection closure as the only indication of completion.

An HTTP persistent connection carries more than one HTTP request/HTTP response exchange over the same connection. HTTP/1.1 uses persistence by default unless its connection rules indicate closure. Reusing the connection avoids establishing a separate connection for every exchange.^[ref]

For a sequential example, a client retrieves /color and reads a response with Content-Length: 4 followed by blue. It then requests /shape on the same connection and reads Content-Length: 6 followed by circle. These are two distinct requests and two distinct responses, each with its own control information and HTTP message framing. Neither resource name nor method is inherited merely because the connection is reused.

This example relies on being able to finish the first message without closing the connection. To retain persistence, the message lengths must be self-defined rather than delimited by closure. A server must read the complete request body or close the connection after responding; otherwise leftover body bytes could be mistaken for a new request. A client likewise must consume the complete response body before reusing the connection.^[ref]

Connection: close signals that the connection will close after the current response. Persistence is not a promise of an unlimited lifetime: a connection can also close unexpectedly. Whether an outstanding operation can be retried automatically depends on its semantics, particularly HTTP idempotence, rather than on the fact that the connection had previously been reusable.^[ref]

Persistence also does not require sending requests before earlier responses arrive. That additional option is HTTP pipelining; in HTTP/1.1, the corresponding responses must retain request order. The sequential example uses persistence without pipelining.^[ref]

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.^[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.^[ref]

An HTTP request is a message asking a server to apply an HTTP request method to a target resource. It includes control information and HTTP header fields, and can include content according to the applicable method and message rules. Its meaning is distinct from the textual framing used by one protocol version.^[ref]

For an illustrative HTTP/1.1 request, the line GET /color?view=plain HTTP/1.1 selects a method and request target, while Host: example.org supplies host information. An empty line ends the header section. These pieces belong to the version's request-line and field syntax.^[ref]

Starting from https://example.org/color?view=plain#legend, the ordinary origin-form target is /color?view=plain. The query string participates in that target, while the fragment identifier does not: fragment processing is performed on the client side rather than by including the fragment in the target sent to the server.^[ref][ref]

The method cannot be inferred from a content string alone. Sending the text blue to an endpoint stipulated to replace a color and sending it to an endpoint stipulated to append a log entry request different operations. The target, method and application contract supply that distinction.

An HTTP request also differs from a returned HTTP response. A successfully transmitted request can receive an error status, and a connection can end before a final response is obtained. Reasoning about the requested operation, its eventual outcome and the transport event as separate observations makes failures easier to interpret.

An HTTP request method identifies the operation requested for an HTTP request's target. The target and method have separate roles: the same resource can be read, replaced or processed according to the chosen method and its defined semantics. Method tokens are case-sensitive.^[ref]

For example, an invented /color resource uses GET to retrieve its current color and PUT to replace that color with the supplied value. One PUT storing blue and two identical such operations leave the same intended color. A different /log resource is stipulated to append each POST value: two appends of x then produce two entries. The append behavior belongs to this example application; it is not a universal definition of every POST.

HTTP idempotence concerns repeated intended effects, not identical response messages. A repeated replacement can leave the same state while returning a different HTTP status code because the resource already exists. An HTTP safe method requests essentially read-only semantics; incidental activities such as logging do not make every safe request a request to change the resource.^[ref]

Cacheability is another property, governed by method and response rules rather than by idempotence alone. Interpret the HTTP request method, HTTP header fields and HTTP response together before deciding what a repeated or cached exchange means.^[ref]

An HTTP response is a message returned in response to an HTTP request, carrying an HTTP status code, associated HTTP header fields and any permitted content. An exchange can include informational responses before its final response.^[ref]

For an invented plain-text resource, a successful GET can return status 200, Content-Type: text/plain; charset=utf-8 and the content blue. These four letters occupy four bytes in UTF-8, so a corresponding content length is four. The HTTP representation's data, its media type and the status describing this exchange have different roles.

A response need not contain a representation body. A successful PUT can return 204 without response content, and a HEAD response carries no content even when the corresponding GET would retrieve data. Interpreting a response therefore requires the request method as well as the status code.^[ref]

In HTTP/1.1, HTTP/1.1 200 OK is a possible status line, followed by field lines, an empty line and any message body allowed by the framing rules. This spelling is one version's concrete syntax for the broader response abstraction.^[ref]

The received content can change between requests while the resource identifier stays the same. Conversely, the same content can accompany different exchange metadata. Inspect status, fields and content together instead of treating any one of them as the entire response or as a guarantee of an application-specific result.

An HTTP status code is a three-digit code in an HTTP response describing the outcome or progress of handling an HTTP request. Its first digit identifies a broad class: informational 1xx, successful 2xx, redirection 3xx, client-error 4xx or server-error 5xx. The particular code and request method refine the meaning.^[ref]

For an invented /color resource, a PUT can store blue and return 204 to indicate successful fulfillment without response content. A later GET can return 200 with the text blue. A HEAD response can also have status 200 while carrying no response content. Thus a successful code does not by itself determine whether there is a body to read.^[ref]

In HTTP/1.1, a status line might be written HTTP/1.1 200 OK. The numerical code supplies the standardized status; the accompanying reason phrase is optional and is not the authority for interpretation. Changing the descriptive phrase does not redefine code 200.^[ref]

An HTTP status code describes this exchange rather than proving that every application-level goal succeeded. A request can be transferred correctly and still receive an error status. Conversely, receiving 200 does not establish that an application-specific calculation inside the returned content is correct. Interpret status, HTTP header fields, content and the application's contract together.

The Hypertext Transfer Protocol is an application-level communication protocol for exchanging requests and responses about resources. In the client-server model, an HTTP request supplies an HTTP request method and target; an HTTP response supplies an HTTP status code and associated information. HTTP header fields convey metadata, and messages can carry content. These semantics are distinct from the particular wire format used by a protocol version.^[ref]

For a concrete exchange, a client can send method GET for https://example.org/manual. A successful response can carry status 200 and an HTML representation of the resource. A response with status 404 instead says that the server did not find a current representation, or is unwilling to disclose one; successful communication does not require successful retrieval.^[ref]

The request's URL identifies the target, while the response describes the outcome of this exchange. A later exchange can return different content or a different status. The protocol's stateless request semantics also do not prevent an application from maintaining state: the distinction concerns what a request must mean, not whether a user can have an ongoing session.^[ref]