HTTP messages are how data is exchanged between a server and a client. There are two types of messages: requests sent by the client to trigger an action on the server, and responses, the answer of the server.
HTTP messages are composed of textual information encoded in ASCII, and spanning over multiple lines. In HTTP/1.1 and earlier versions of the protocol, these messages were directly sent over the connection. In HTTP/2, the human-readable message is mangled into HTTP frames allowing optimizations and better performance.
Web developers, or webmasters, rarely craft the textual HTTP messages themselves: the piece of software, a browser, a proxy, or a Web server, are in charge of that. They control it through config files (for proxies or servers), through APIs (for browsers), or through other interfaces.
The HTTP/2 binary framing mechanism has been designed so that it doesn't need any adaptation of the APIs or config files used: it is mostly transparent for the user controlling the equipment.
Both, HTTP requests and responses, share a similar structure and are composed of:
- A start-line that describes the requests to be performed, or its status that is a success or a failure. This start-line is always a single line.
- An optional set of HTTP headers specifying the request, or describing the body included in the message.
- A blank line indicating that all meta-information for the request have been sent.
- An optional body that contains data associated with the request (like the content of an HTML form), or the document associated with a response. The presence of the body and its size is defined by the start-line and the HTTP headers.
The start-line and the HTTP headers are called the head of the requests, in opposition to the payload, the body.
HTTP Requests
Start line
HTTP requests are messages sent by the client to initiate an action on the server. Their start-line contains of three elements:
- An HTTP method, a verb (like {{HTTPMethod("GET")}}, {{HTTPMethod("PUT")}} or {{HTTPMethod("POST")}}) or a noun (like {{HTTPMethod("HEAD")}} or {{HTTPMethod("OPTIONS")}}), that describes the action to be performed. For example,
GETindicates that a resource should be fetched orPOSTmeans that data is pushed to the server (that may create or modify a resource, or generate a temporary document to send back). - The request target, usually a {{glossary("URL")}}, or only the absolute path part of it as the protocol, port, and domain are defined by the context most of the time. The format of this request target varies between the different HTTP methods. It can be
- An absolute path, eventually followed by a
'?'and a query string. This is the most common form, called origin form, and is used withGET,POST,HEAD, andOPTIONSmethods.
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0 - A complete URL, the absolute form, mostly used with
GETwhen connected to a proxy.
GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1 - The authority component of an URL, that is the domain name and optionally the port (prefixed by a
':'), called the authority form. It is only used withCONNECTwhen setting up an HTTP tunnel.
CONNECT developer.mozilla.org:80 HTTP/1.1 - The asterisk form, a simple asterisk (
'*') used withOPTIONSand representing the server as a whole.
OPTIONS * HTTP/1.1
- An absolute path, eventually followed by a
- The HTTP version, that defines the structure of the rest of the message, and acts as an indicator of the version to use for the response.
Headers
HTTP headers in a request follow the basic structure of any HTTP header: a case-insensitive string followed by a colon (':') and a value whose structure depends upon the header. The whole header, including the value, consists of one single line, that can be quite long.
There are numerous request headers available. They can be divided in several groups:
- General headers, like {{HTTPHeader("Via")}}, apply to the message as a whole.
- Request headers, like {{HTTPHeader("User-Agent")}}, {{HTTPHeader("Accept-Type")}}, modify the request by specifying it further (like {{HTTPHeader("Accept-Language")}}), by giving context (like {{HTTPHeader("Referer")}}), by conditionally restricting it (like {{HTTPHeader("If-None")}}).
- Entity headers, like {{HTTPHeader("Content-Length")}} that applies to the body of the request. Obviously there is no such header transmitted when there is no body in the request.
Body
The last part of a request is its body. Not all requests have one: requests fetching resources, like GET or HEAD usually don't need any, DELETE or OPTIONS neither. Some requests send data to the server in order to update it: this is often the case of POST requests (that can have HTML form data).
Bodies can be broadly divided into two categories:
- Single-resource bodies consisting of one single file, defined by the two headers: {{HTTPHeader("Content-Type")}} and {{HTTPHeader("Content-Length")}}.
- Multiple-resource bodies consisting of a multipart body, each containing a different bit of information. This is typically used in association with HTML Forms.
HTTP Responses
Status line
The start line of an HTTP response, called the status line, contains the following information:
- The protocol version, usually
HTTP/1.1. - A status code indicating success or failure of the request. Common status code are {{HTTPStatus("200")}}, {{HTTPStatus("404")}}, or {{HTTPStatus("302")}}
- A status text, purely informational, that is a textual short description of the status code, helping humans to understand HTTP messages.
A typical status line looks like: HTTP/1.1 404 Not Found.
Headers
HTTP headers for request follow the basic structure of any header: a case-insensitive string followed by a colon (':') and a value whose structure depends upon the type of the header. The whole header, including the value, stands in one single line.
There are numerous request headers available. They can be divided in several groups:
- General headers, like {{HTTPHeader("Via")}}, apply to the message as a whole.
- Response headers, like {{HTTPHeader("Vary")}} and {{HTTPHeader("Accept-Ranges")}}, give additional information about the server that don't fit in the status line.
- Entity headers, like {{HTTPHeader("Content-Length")}}, apply to the body of the request. Obviously there is no such headers transmitted when there is no body in the request.
Body
The last part of a response is the body. Not all responses have one: responses with status code like {{HTTPStatus("201")}} or {{HTTPStatus("204")}} usually don't have any.
Bodies can be broadly divided into three categories:
- Single-resource bodies consisting of a single file of known length, defined by the two headers: {{HTTPHeader("Content-Type")}} and {{HTTPHeader("Content-Length")}}.
- Single-resource bodies consisting of a single file of unknown length, encoded by chunks with {{HTTPHeader("Transfer-Encoding")}} set to
chunked. - Multiple-resource bodies consisting of a multipart body, each containing a different bit of information. These are pretty rare.
HTTP/2 Frames
HTTP/1.x messages have a few drawbacks for performance:
- Headers, unlike bodies, are uncompressed.
- Headers are often very similar from one message to the next one, but they are still repeated on the wire.
- No multiplexing can be done. Several connections are opened to the same server: warm TCP connections are more performant than cold ones.
HTTP/2 introduces an extra step: it divides HTTP/1.x messages in frames that are embedded in a stream. Data and header frames are separated, allowing for header compression. Several streams can be combined together, a process called multiplexing, allowing the underlying TCP connection to be more efficient.
HTTP frames are transparent for Web developers. It is an extra step between HTTP/1.1 messages and the underlying transport protocol. No change is needed in the APIs used by Web developers; as soon as they are available both in the browser and in the server, HTTP/2 is switched on and used.
Conclusion
HTTP messages are the key in controlling HTTP; their structure is simple and they are very extensible. The HTTP/2 framing mechanism adds a new intermediate layer between the HTTP/1.x syntax and the underlying transport protocol but doesn't fundamentally modify it: it builds on the existing proven mechanisms.