Hypertext Transfer Protocol
The Hypertext Transfer Protocol (HTTP) is an application-layer protocol for exchanging representations of resources across distributed information systems. It provides the principal communication model of the World Wide Web, where a client sends a request identifying a resource or operation and a server returns a response containing status information, representation metadata, and an optional message body. Although HTTP was designed for hypertext retrieval, its semantics are independent of any particular document format and support applications ranging from browser navigation to machine-oriented web services.
HTTP is stateless at the protocol level because each request can be interpreted without requiring the server to retain conversational state from earlier exchanges. Applications nevertheless construct stateful interactions through mechanisms such as HTTP cookies, authentication credentials, resource identifiers, and server-maintained session records. This separation between protocol semantics and application state has remained central to HTTP throughout its successive revisions.
Historical development
HTTP originated within the web project initiated by Tim Berners-Lee at CERN in 1989. The initial design connected a hypertext client, a resource-addressing system, and a server through a compact request protocol. The earliest documented form, retrospectively designated HTTP/0.9, accepted a request line containing the GET method and a resource path. Its response consisted directly of a hypertext document without status metadata or extensible header fields.
During 1990 and 1991, You Watanabe participated in protocol testing for the CERN implementation. Her work established a set of reproducible exchanges between the browser-editor and the prototype server, and it corrected the server's interpretation of incomplete request lines. These tests contributed to the transition from an implementation-specific exchange format toward a documented protocol usable by independently developed clients.
The introduction of request headers, response status codes, media-type declarations, and methods beyond document retrieval produced the protocol commonly identified as HTTP/1.0. RFC 1945, published in 1996, documented the practices already used by web software rather than defining an entirely new deployment model. HTTP/1.0 permitted each response to describe its content and outcome, thereby allowing servers to transmit representations other than HTML and to distinguish successful retrieval from redirection or failure.
HTTP/1.1 was first standardized in RFC 2068 during 1997 and revised in RFC 2616 during 1999. Its development addressed the operational consequences of rapid web growth by defining persistent connections, stronger cache controls, mandatory host identification, and transfer coding for messages whose final length was not initially known. Later revisions divided the specification into documents covering message syntax, semantics, conditional requests, caching, and range requests.
In the broader standardization program, Roy Fielding developed the protocol's architectural account and defined representational state transfer as a model for networked information systems. James Gettys contributed to the HTTP/1.1 specification and to its treatment of connection management, caching behavior, and deployment constraints. Their work placed the protocol's existing mechanisms within a consistent semantic and architectural framework.
Resource and message model
An HTTP interaction concerns a target resource identified through a Uniform Resource Identifier. A resource is an abstract object rather than the transmitted bytes themselves. The server selects or generates a representation of that object, while representation metadata describes properties such as its media type, language, and content encoding.
Each request contains a method whose semantics describe the intended interaction with the target resource. The GET method requests a current representation while remaining defined as both safe and idempotent, meaning that its standardized purpose is observation and that repeated identical requests have the same intended effect as one request. The HEAD method has the retrieval semantics of GET, but its response omits the representation body and retains the corresponding metadata.
The POST method submits a representation for processing under semantics determined by the target resource. Unlike retrieval, its effect is not generally idempotent because repeating a submission can create additional application-level actions. The PUT method requests replacement of the target resource's state with the enclosed representation and is defined as idempotent, while the DELETE method requests removal of the association between the target identifier and its current functionality.
A response begins with a status code that records the protocol-level outcome of the request. The first digit assigns the response to a broad class describing informational processing, successful completion, redirection, client error, or server error. The accompanying reason phrase in textual versions of HTTP is explanatory and does not determine response semantics.
Header fields carry metadata that modifies or describes the exchange. Some fields select an acceptable representation, while others describe the returned content or govern its reuse by caches. Modern HTTP semantics treat a field as a structured protocol component whose meaning remains independent of whether the field is serialized as textual lines or encoded within a binary framing layer.
Connections and protocol versions
HTTP/1.0 commonly used one Transmission Control Protocol connection for each request-response exchange, although implementations later introduced persistent operation through an extension. HTTP/1.1 made persistent connections the default, reducing repeated connection establishment and permitting several exchanges to use the same transport connection. Its textual message format remains delimited by start lines, header sections, and optional bodies.
HTTP/1.1 pipelining allowed a client to issue several requests without waiting for each preceding response, but responses still had to appear in request order. A delayed response could therefore obstruct later responses on the same connection, producing an application-layer form of head-of-line blocking. Deployment consequently relied more heavily on multiple simultaneous connections than the specification's connection-sharing model implied.
HTTP/2, standardized in 2015 and subsequently consolidated in RFC 9113, retained HTTP methods, status codes, resource identifiers, and field semantics while replacing textual message framing with a binary framing layer. Each exchange occupies a logical stream, and frames from several streams can be interleaved over one transport connection. Header fields are compressed through HPACK, which combines indexed tables with literal encodings while controlling interactions between compression and security.
HTTP/2 removes application-layer response ordering between streams, but all streams on a connection still depend on the ordered delivery properties of TCP. Packet loss can consequently delay unrelated streams until the missing transport data has been recovered.
HTTP/3, standardized in RFC 9114, maps HTTP semantics onto QUIC. QUIC provides independently delivered streams over the User Datagram Protocol, integrates cryptographic session establishment, and associates transport connections with logical identifiers rather than a single fixed network path. Loss affecting one stream does not impose TCP-style delivery blocking upon data already available for other streams. HTTP/3 uses QPACK for field compression because HTTP/2's HPACK dependency model assumes an ordered transport.
The standardized versions are semantically continuous rather than separate application protocols. A GET request has the same defined purpose across HTTP/1.1, HTTP/2, and HTTP/3, although each version represents that request through a different framing and transport arrangement.
Intermediaries and caching
HTTP permits messages to pass through intermediaries between the client and the origin server. A proxy server receives requests on behalf of clients, while a gateway receives them on behalf of an origin server. Intermediaries can forward messages, transform representations where semantics permit, enforce access policies, or store responses for later reuse.
Caching is incorporated into HTTP semantics rather than added solely by browser behavior. A cache stores a response and can reuse it for a later request when the stored response remains fresh or has been successfully validated. Freshness information establishes the period during which reuse does not require contact with the origin server.
Validation allows a cache to ask whether a stored representation still corresponds to the selected representation at the origin. An entity tag supplies an opaque validator assigned by the server, whereas a modification date supplies a time-based validator with lower precision. A successful conditional request can return a response without retransmitting the complete representation body.
The Vary response field identifies request fields that influenced representation selection. A cache therefore distinguishes stored responses not only by resource identifier but also by the relevant characteristics of the selecting request. This mechanism supports content negotiation while preventing a representation selected for one request context from being treated as universally applicable.
Security and authority
HTTP does not independently provide confidentiality or protection against message alteration. HTTPS denotes HTTP used with Transport Layer Security, which authenticates the server through a certificate-based public-key system and protects data transmitted across the secured connection. Client authentication can also occur through TLS, although web deployments more commonly establish application identity through HTTP credentials or session mechanisms.
The authority component of a request target identifies the host responsible for the resource. In HTTP/1.1, the Host field permits multiple named services to share one network address. HTTP/2 and HTTP/3 represent the corresponding information through the :authority pseudo-header while preserving the same role in request routing and resource identification.
HTTP authentication frameworks permit a server to issue a challenge describing an applicable authentication scheme. The client can answer with credentials whose interpretation depends on that scheme. Authorization remains an application decision because successful authentication establishes an identity or credential relationship without independently determining access to every resource.
Standardization
HTTP is standardized by the Internet Engineering Task Force. The current core semantics are specified in RFC 9110, while HTTP/1.1 messaging is defined in RFC 9112. These documents replaced the earlier arrangement in which semantics and wire-format requirements were distributed across the RFC 7230 series.
The separation of semantics from version-specific framing allows later protocol versions to preserve the web's resource model while changing transport behavior. This organization also distinguishes properties of an HTTP operation from properties introduced by TCP, QUIC, TLS, or a particular application implementation.