HTTP, HyperText Transfer Protocol, is the foundational communication protocol of the World Wide Web. It defines the rules by which browsers and web servers communicate, how a browser requests a resource, how a server responds, what headers accompany those requests and responses, and how different types of content are identified and transferred. Every time a browser loads a web page, fetches an image, submits a form, or makes an API call it is using HTTP, or its secure variant HTTPS: to communicate with servers.

The HyperText in HTTP refers to the original use case, transferring HTML documents, the hypertext format of the web. In practice HTTP is used to transfer all types of web content, HTML pages, images, JavaScript files, CSS stylesheets, JSON data, video streams, and anything else a browser or application might need to retrieve from a server. The protocol is flexible and extensible enough that it has expanded far beyond its original hypertext document transfer purpose to become the universal application layer protocol of the internet.

HTTP is a client-server protocol, communication is initiated by the client, typically a browser, and responded to by the server. The client sends an HTTP request specifying what it wants. The server processes the request and sends an HTTP response containing the requested content or an indication of what happened, a success, a redirect, an error. Every web interaction at its most fundamental level is an HTTP request-response cycle.

How HTTP works

HTTP operates as a stateless request-response protocol, each request-response pair is independent and the server retains no memory of previous requests by default. Understanding the basic mechanics of HTTP requests and responses clarifies how every web interaction functions and how redirects fit into this communication model.

HTTP request: a browser initiates an HTTP request to access a resource at a specific URL. The request contains several components.

The request method, GET, POST, PUT, DELETE, HEAD, OPTIONS, PATCH, specifies what action the client wants to perform. GET requests retrieve a resource. POST requests submit data to be processed. PUT and PATCH requests update a resource. DELETE requests remove a resource. HEAD requests retrieve only the response headers without the body. The request method is fundamental to how servers interpret the request and is important in redirect handling, some redirect status codes preserve the request method while others switch it to GET.

The request URL, the specific resource being requested. The URL includes the path and optionally query parameters.

Request headers, metadata accompanying the request. The Host header specifies the domain being accessed, essential for servers hosting multiple domains. The User-Agent header identifies the browser or client. The Accept header specifies what content types the client can handle. The Cookie header sends stored cookies. Many other headers serve specific purposes in the HTTP specification.

The request body, for POST, PUT, and PATCH requests the body contains the data being submitted, form data, JSON payloads, file uploads. GET requests typically have no body.

HTTP response: the server processes the request and sends back an HTTP response containing several components.

The HTTP status code: the three-digit code that summarises the outcome. 200 OK for successful requests. 301 Moved Permanently for permanent redirects. 404 Not Found for missing resources. 500 Internal Server Error for server failures. The status code is the most important single piece of information in the response, it tells the client what happened and what to do next.

Response headers, metadata about the response. Content-Type specifies what kind of content the body contains. Content-Length specifies the size of the body. Cache-Control specifies caching instructions. Location specifies the redirect destination for 3xx responses. Set-Cookie instructs the browser to store cookies. Many other headers serve specific purposes.

The response body, the actual content being returned. For a successful page request this is the HTML of the page. For an image request this is the image data. For a redirect response the body is typically empty or contains a minimal HTML page with a link to the redirect destination, the browser ignores the body and follows the Location header.

HTTP versions

HTTP has evolved through several major versions, each improving performance, security, and capability while maintaining backward compatibility with the fundamental request-response model.

HTTP/1.0: the first standardised version of HTTP, defined in 1996. Each request required a separate TCP connection, connecting, making one request, receiving the response, and closing the connection. For pages with many resources, each requiring a separate connection, this was extremely inefficient. HTTP/1.0 had no persistent connections, no virtual hosting through the Host header, and no caching headers.

HTTP/1.1: released in 1997 and remaining the dominant version for many years. HTTP/1.1 introduced persistent connections, a single TCP connection could handle multiple sequential requests without reconnecting for each. The Host header became mandatory, enabling virtual hosting where multiple domains are served from the same IP address. Caching headers, chunked transfer encoding, and other features significantly improved performance and capability. HTTP/1.1 is the baseline protocol that all web infrastructure understands.

HTTP/2: standardised in 2015 and now widely deployed. HTTP/2 introduced multiplexing, multiple requests and responses can be in flight simultaneously over a single TCP connection rather than waiting sequentially. Header compression reduces the overhead of repeated headers. Server push allows servers to proactively send resources the client will need before they are requested. HTTP/2 requires HTTPS in all major browser implementations, making HTTPS a practical prerequisite for HTTP/2’s performance benefits. HTTP/2 typically delivers pages significantly faster than HTTP/1.1.

HTTP/3: the newest major version, standardised in 2022. HTTP/3 replaces TCP with QUIC, a transport protocol built on UDP, eliminating TCP’s head-of-line blocking problem where a lost packet stalls all streams on a connection. QUIC integrates TLS encryption at the transport layer, reducing connection establishment time. HTTP/3 provides the best performance, particularly on unreliable network connections, and is increasingly deployed by major platforms and CDNs.

HTTP methods and redirects

The HTTP request method, GET, POST, PUT, DELETE, and others, interacts with redirect handling in ways that affect how redirect status codes behave and which codes are appropriate in different situations.

GET requests and redirects: the most common HTTP method for browser navigation. GET requests retrieve resources, clicking a link, typing a URL, loading a page. All 3xx redirect status codes work straightforwardly with GET requests, the browser receives the redirect response and makes a GET request to the Location URL. No method change occurs.

POST requests and redirects: POST requests submit data, form submissions, login attempts, API calls that create resources. The handling of POST requests through redirects is where method preservation becomes significant.

301 and 302 redirects historically caused browsers to switch POST requests to GET when following the redirect, though the original HTTP specification said the method should be preserved. This browser behaviour became so universal that it is now the de facto standard.

303 redirects explicitly instruct browsers to switch to GET when following the redirect, used deliberately in Post/Redirect/Get patterns after form submissions to prevent resubmission on page refresh.

307 and 308 redirects preserve the original method, a POST remains a POST at the redirect destination. These are used in API contexts where method preservation is important.

HEAD requests: a HEAD request retrieves only the response headers without the response body, useful for checking if a resource exists or what headers it returns without downloading the content. HEAD requests follow redirects the same way GET requests do, receiving the redirect response and making a HEAD request to the Location URL.

HTTP headers and redirect management

HTTP headers are the metadata layer of HTTP communication, carrying essential information about requests and responses. Several specific headers are directly relevant to redirect management.

Location header: the most important header in redirect management. When a server returns a 3xx redirect status code the Location header contains the URL the browser should navigate to. Without a Location header a 3xx response is incomplete and the browser has nowhere to redirect to. The Location header value is the redirect destination: the URL that browsers and crawlers follow.

Host header: the request header that specifies which domain is being requested. For servers hosting multiple domains, including redirect management infrastructure handling many connected domains, the Host header tells the server which domain’s redirect rules to apply. A redirect management server receiving a request checks the Host header to identify which connected domain is being requested and applies that domain’s configured redirect rules.

Referer header: the request header that specifies the URL of the page from which the current request originated. Sent by browsers when navigating from one page to another, providing referral data that web analytics tools use for traffic source attribution. HTTPS-to-HTTP referrer data is dropped by browsers, requests from HTTPS pages to HTTP pages do not include the Referer header. This is one of the reasons HTTP sites lose analytics attribution data from HTTPS traffic sources.

Cache-Control header: the response header that instructs browsers and CDNs how to cache the response. For 301 permanent redirects the Cache-Control header determines how long browsers cache the redirect, a cached permanent redirect means the browser goes directly to the destination on subsequent requests without querying the server. For 302 temporary redirects the redirect is typically not cached, browsers re-check the redirect source on each visit.

HSTS header, Strict-Transport-Security: the response header that instructs browsers to only connect to the domain over HTTPS in the future, eliminating HTTP connections entirely rather than redirecting them. An HSTS header with a long max-age tells browsers to cache the HTTPS requirement for the specified duration, making the HTTP to HTTPS redirect unnecessary for returning visitors.

HTTP and redirect performance

HTTP performance directly affects redirect performance, every redirect hop involves at least one HTTP round trip, and the efficiency of that round trip determines how much latency the redirect adds.

Round trip time: each HTTP request-response cycle involves a network round trip, the request travels from the browser to the server and the response travels back. Round trip time depends on the geographic distance between browser and server, network conditions, and server response time. A redirect adds at least one full round trip of latency, the request to the redirect source URL and the redirect response back, before the browser can make the request to the destination.

Connection establishment overhead: each new HTTPS connection involves a TLS handshake before the first HTTP request can be sent, adding one to two additional round trips. When a redirect goes to a different domain, requiring a new connection to a different server, the TLS handshake overhead is paid again. Redirect chains that cross multiple domains can accumulate significant connection establishment overhead.

HTTP/2 and connection reuse: HTTP/2’s connection reuse means that redirects within the same domain, or between domains served from the same connection in multi-domain configurations, benefit from the existing connection rather than requiring new connection establishment. HTTP/2’s performance advantages are most pronounced when connections can be reused, reducing the overhead of redirect handling on the same infrastructure.

DNS lookup for redirect destinations: when a redirect points to a destination on a different domain the browser must perform a DNS lookup for the destination domain before it can establish a connection. DNS lookups add 20 to 100 milliseconds of latency per lookup. Redirect chains that cross multiple domains accumulate DNS lookup overhead at each hop, another reason to minimise redirect hops and avoid chains.

HTTP and modern web development

HTTP is the foundation on which all web technologies are built, understanding it is fundamental to understanding how the web works and how all higher-level technologies relate to each other.

REST APIs: Representational State Transfer APIs use HTTP as their communication protocol. REST APIs use HTTP methods semantically, GET to retrieve resources, POST to create, PUT to replace, PATCH to update, DELETE to remove. HTTP status codes indicate API call outcomes. REST is the dominant architectural style for web APIs because HTTP is universally supported and its request-response model maps naturally to API operations.

WebSockets: WebSockets provide full-duplex communication, ongoing bidirectional data streams, between browsers and servers. WebSocket connections begin as HTTP connections and are upgraded to the WebSocket protocol through an HTTP upgrade mechanism. HTTP provides the initial handshake and connection establishment while WebSockets take over for ongoing bidirectional communication.

Service workers: service workers are browser-side scripts that intercept HTTP requests, enabling offline functionality, caching strategies, and background synchronisation. Service workers sit between the browser and the network, intercepting HTTP requests and either fulfilling them from cache or allowing them to proceed to the network. Advanced caching and offline capabilities in modern web applications are built on service workers’ ability to intercept and handle HTTP requests programmatically.

Content Delivery Networks: CDNs intercept HTTP requests at geographically distributed edge locations, responding to requests from the nearest edge server rather than routing all traffic to the origin. CDNs improve performance by reducing round trip times and can implement redirect rules at the edge, returning redirect responses before requests reach the origin server.

HTTP vs HTTPS, when HTTP is acceptable

Given the security benefits of HTTPS and its importance as a ranking signal the question of when HTTP is acceptable has a straightforward answer, almost never for public-facing web content.

HTTP for internal development: accessing services on localhost, http://localhost:3000: or on local development networks over HTTP is standard practice and appropriate. Development environments typically do not have SSL certificates and the security risk on a local network is minimal.

HTTP as redirect source: HTTP URLs serve an important role as redirect sources, the HTTP version of every domain should redirect to HTTPS. The HTTP protocol must be available on port 80 to receive these HTTP requests and return redirect responses. This is a legitimate HTTP endpoint, accepting connections and immediately redirecting them to HTTPS.

HTTP in API testing and automation: internal API testing environments may use HTTP for simplicity. External-facing APIs should use HTTPS, but internal testing and development environments may reasonably use HTTP.

For all public-facing websites, APIs, and services the answer is clear, HTTPS is the baseline and HTTP should be used only as a redirect source that immediately upgrades connections to HTTPS.