Hypertext Transfer Protocol (HTTP) is one of the internet's foundational protocols, enabling reliable communication between clients and servers at the application layer (Layer 7) of the Open Systems Interconnection (OSI) model. Powering human-computer interaction, the HTTP protocol allows clients to request or manipulate data using HTTP requests. Web browsers rely heavily on the protocol to enable this.

How does HTTP work?

HTTP transfers data in the form of requests, which contain a version, requested resource, HTTP method, request headers, and an optional request body. Here's why each portion matters: 

  • The HTTP version type denotes which version of the HTTP protocol is being used. Not only do different HTTP versions (such as HTTP/1.1 or HTTP/2, for example) support different features, but also determine how a given request is processed. 

  • The requested resource is denoted by a Uniform Resource Locator (URL) pointing to  an asset such as a PDF, JavaScript, or CSS file, or an HTML webpage. This resource lives on the web server. 

  • The HTTP method describes to the server how to interact with the targeted resource. This can be either GET (retrieve data), POST (create or update a resource), PUT (replace existing resource data), DELETE, or a number of other standard methods. 

  • The request headers let the client pass information such as user agent, formatting and encoding instructions, connection parameters (such as keep-alive), caching, and more to the web server. 

  • The request body contains data sent from the client to the web server—such as form data—which provides additional context and instructions. Most HTTP requests don't include a request body. 

Each HTTP request generates a response from the web server which it sends back to the client. Responses contain data based on the resource accessed according to the client's needs. An HTTP response can include the following components:

  • HTTP response headers, which contains detailed contextual information about the response including Server name, Content-Type, Connection parameters, Content-Encoding method, an embedded status code, and (potentially) much more. 

  • An optional HTTP response body, which can contain what the browser should display upon receipt,  or other contextual information. HTML data is commonly included here.

Understanding HTTP status codes

The status codes mentioned above can vary pretty widely depending on the success or failure of the request. A web server can generate the following common HTTP status codes: 

  • 200 – OK/success (the request worked as expected)

  • 301 – Permanent redirect (for mapping old URLs to new URLs)

  • 302 – Temporary redirect

  • 404 – Page not found (server couldn't locate the requested resource)

  • 500 – Internal server error (server isn't working as expected) 

  • 503 – Service unavailable (the server is temporarily unavailable due to load or maintenance)

These common codes overlap with status code ranges, each of which signify a different status category. Here's what they represent: 

  • 100 to 199 – The server is actively processing the request while providing context. 

  • 200 to 299 – The request was processed and responded to successfully.  

  • 300 to 399 – You've been redirected to an alternate URL.

  • 400 to 499 – The resource couldn't be located, or other client-side errors. 

  • 500 to 599 – The server is experiencing some sort of error, preventing the request from being completed.

Understanding HTTP versions

While the HTTP protocol debuted in 1991 (technically as HTTP/0.9), multiple versions have since iterated on that foundation. Subsequent HTTP versions have added new features, performance enhancements, and security measures. Here's a brief summary: 

  • HTTP/0.9 was the first version of HTTP and supported GET requests only. It allowed clients to request and receive HTML documents. Responses were extremely simple. This was known as "the one-line protocol" in some circles. 

  • HTTP/1.0 added extensibility to the protocol including new headers and fields, status codes, new request methods (HEAD and POST), and support for different file types using the Content-Type header. 

  • HTTP/1.1 added caching, a Content Negotiation mechanism (supporting multiple languages and encodings) to improve client-server communication, and connection reuse. 

  • HTTP/2 added a new binary format alongside a new Compression header and multiplexing for concurrent request processing (mitigating head-of-line blocking). 

  • HTTP/3 (or HTTP/3 over QUIC) leverages the QUIC (Quick UDP Internet Connections) transport layer protocol—and therefore UDP—instead of TCP. An updated header compression algorithm called QPACK supports improved data streaming, which is a major UDP use case.

Does HAProxy support HTTP? 

Yes! All HAProxy products support HTTP, being one of the most important internet protocols used today. We can load balance any HTTP application using a variety of load balancing algorithms, while supporting core performance features such as pipelining, multiplexing, connection pooling, and HTTP compression. HAProxy Enterprise also supports applications using any version of the HTTP protocol. 

To learn more about HTTP support in HAProxy, check out our Configuration Manual or our blog post, Your Comprehensive Guide to HAProxy Protocol Support.