What Is HTTP

HTTP (HyperText Transfer Protocol) is the communication protocol that governs how web browsers and servers exchange data. Originally designed by Tim Berners-Lee in 1991 alongside the World Wide Web, HTTP/0.9 could only transfer HTML documents. The same protocol now carries everything from HTML pages and images to JSON API responses and streaming video. The specification was reorganized in June 2022 into RFC 9110 (semantics), RFC 9111 (caching), and RFC 9112 (HTTP/1.1 message syntax), which obsoleted the long-cited RFC 2616 and RFC 7230 series.

When you type a URL into your browser, an HTTP request is sent to the server, which processes it and returns an HTTP response - this round trip is the fundamental mechanism behind every web page you visit. HTTP is a stateless protocol, meaning each request is independent and carries no memory of previous interactions. Maintaining state (such as login sessions) requires mechanisms like cookies or authentication tokens.

Request and Response Structure

HTTP communication follows a simple client-server model: the client sends a request, and the server returns a response.

The method (GET, POST, PUT, DELETE) specifies the intended action. The URL path identifies the target resource. Headers carry metadata such as browser type (User-Agent), accepted formats (Accept), and authentication credentials (Authorization). POST and PUT requests include a body containing form data or JSON payloads.

The status code (200, 404, 500) indicates the result. Headers include content type (Content-Type), caching directives (Cache-Control), and security headers. The body contains the actual data - HTML, JSON, image binary, or other content.

GET requests retrieve resources and normally carry no body: RFC 9110 states that content in a GET request has no generally defined semantics and that a client should not send it. POST submits data (form submissions, API calls) with a body. REST APIs also use PUT (update), DELETE (remove), and PATCH (partial update) extensively.

Key Status Codes

HTTP status codes are three-digit numbers that categorize server responses. The first digit determines the category.

200 OK means the request succeeded. 201 Created confirms a new resource was created. 204 No Content indicates success with no response body (common after DELETE).

301 Moved Permanently signals a permanent URL change. Google says its indexing pipeline uses the redirect as a signal that the target should be the canonical URL. 302 Found is a temporary redirect. 304 Not Modified tells the client its cached version is still valid.

400 Bad Request for malformed syntax. 401 Unauthorized when authentication is required. 403 Forbidden when access is denied. 404 Not Found when the resource does not exist. 429 Too Many Requests when rate limits are exceeded.

500 Internal Server Error is a generic server failure. 502 Bad Gateway occurs when a reverse proxy receives an invalid response from the backend. 503 Service Unavailable indicates temporary downtime due to maintenance or overload.

Proper use of status codes is critical in API design - they enable clients to handle errors gracefully and simplify debugging.

HTTP Version Evolution

HTTP has undergone significant evolution over the three decades since HTTP/0.9 in 1991, with each version addressing performance bottlenecks of its predecessor.

Still in widespread use as of August 2026. Specified in RFC 2068 in January 1997 and reorganized as RFC 9112 in June 2022. Introduced persistent connections (Keep-Alive), chunked transfer encoding, and virtual hosting via the Host header. However, only one request can be processed at a time per TCP connection, causing Head-of-Line Blocking where a slow response delays all subsequent requests.

Based on Google's SPDY protocol, standardized as RFC 7540 in May 2015 and revised as RFC 9113 in June 2022. Enables multiplexing - multiple requests and responses in parallel over a single TCP connection - while header compression (HPACK) reduces overhead. Server push, which delivers resources before the client asks for them, is also specified, but Chrome disabled it by default in Chrome 106 (September 2022) and points to 103 Early Hints as the replacement. TCP-level Head-of-Line Blocking also remains an issue.

Standardized as RFC 9114 in June 2022. Replaces TCP with QUIC (UDP-based, RFC 9000), eliminating TCP Head-of-Line Blocking entirely. The initial handshake takes 1-RTT, and 0-RTT resumption is available for a peer the client has reached before. Because a session is identified by a connection ID rather than an IP address, connections survive network transitions such as Wi-Fi to cellular. Servers advertise availability through the Alt-Svc header, and clients without support fall back to HTTP/2 or earlier.

HTTP/2 and HTTP/3 effectively require HTTPS. Major browsers do not support unencrypted HTTP/2, and HTTP/3's QUIC protocol has TLS 1.3 built in. Protocol speed improvements and security enhancements go hand in hand.

HTTP vs HTTPS

HTTP transmits data in plaintext, making it vulnerable to eavesdropping and tampering by anyone on the network path. HTTPS adds a TLS encryption layer on top of HTTP, securing the communication channel.

HTTP: Uses port 80. Data is unencrypted. As of August 2026 Chrome labels such pages "Not Secure", and Chrome and Safari try to upgrade HTTP page navigations to HTTPS automatically.
HTTPS: Uses port 443. TLS-encrypted. Google announced in August 2014 that it had started using HTTPS as a ranking signal, describing it at the time as a very lightweight signal affecting fewer than 1% of global queries.

HTTP remains the underlying protocol even where HTTPS is the de facto standard. The request-response model, methods, headers, and status codes are identical in both - HTTPS simply wraps the HTTP exchange in an encrypted tunnel. Understanding HTTP fundamentals is essential for working with HTTPS, debugging with developer tools, and designing APIs.

One practical pitfall is judging encryption by what the address bar looks like. Chrome retired the padlock in Chrome 117 (September 2023) and replaced it with a "tune" icon that opens site settings, so the check has to be whether the scheme is https:// rather than whether a padlock is present. HTTPS also guarantees only channel encryption and the identity of the domain reached; it says nothing about whether the operator is trustworthy or the content accurate, since phishing sites can obtain free certificates too.

Common Misconceptions

HTTP and HTTPS are completely different protocols: HTTPS is HTTP with TLS encryption added on top. The request-response structure, methods, and status codes are identical. If you understand HTTP, you understand the mechanics of HTTPS - the difference is the TLS encryption layer plus the URL scheme and default port (80 versus 443) that come with it.
Upgrading to HTTP/2 or HTTP/3 always makes sites faster: HTTP/2 multiplexing and HTTP/3 QUIC improve network-level efficiency, but if the bottleneck is server-side processing, database queries, or frontend rendering, the perceived speed may not change. Protocol upgrades optimize the transport layer, not the entire application stack.
HTTP is an obsolete technology no longer in use: HTTPS became the de facto standard for public websites, but as of August 2026 HTTP is still widely used in internal networks, development environments, and IoT devices. HTTP also forms the foundation of HTTPS - the protocol itself is the same, with TLS encryption layered on top.

HTTP