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 from the server.
HTTP messages are composed of textual information encoded in ASCII, and span over multiple lines. In HTTP/1.1, and earlier versions of the protocol, these messages were openly sent across the connection. In HTTP/2, the once human-readable message is now divided up into HTTP frames, providing optimization and performance improvements.
Web developers, or webmasters, rarely craft these textual HTTP messages themselves: software, a Web browser, proxy, or Web server, perform this action. They provide HTTP messages through config files (for proxies or servers), APIs (for browsers), or other interfaces.
The HTTP/2 binary framing mechanism has been designed to not require any alteration of the APIs or config files applied: it is broadly transparent to the user.
HTTP requests, and responses, share similar structure and are composed of:
The start-line and HTTP headers of the HTTP message are collectively known as the head of the requests, whereas its payload is known as the body.
HTTP requests are messages sent by the client to initiate an action on the server. Their start-line contain three elements:
POST) or a noun (like
OPTIONS), that describes the action to be performed. For example,
GETindicates that a resource should be fetched or
POSTmeans that data is pushed to the server (creating or modifying a resource, or generating a temporary document to send back).
'?'and query string. This is the most common form, known as the origin form, and is used with
POST / HTTP 1.1
GET /background.png HTTP/1.0
HEAD /test.html?query=alibaba HTTP/1.1
OPTIONS /anypage.html HTTP/1.0
GETwhen connected to a proxy.
GET http://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
':'), is called the authority form. It is only used with
CONNECTwhen setting up an HTTP tunnel.
CONNECT developer.mozilla.org:80 HTTP/1.1
'*') is used with
OPTIONS, representing the server as a whole.
OPTIONS * HTTP/1.1
HTTP headers from a request follow the same basic structure of an 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, consist of one single line, which can be quite long.
There are numerous request headers available. They can be divided in several groups:
Via, apply to the message as a whole.
Accept-Type, modify the request by specifying it further (like
Accept-Language), by giving context (like
Referer), or by conditionally restricting it (like
Content-Lengthwhich apply to the body of the request. Obviously there is no such header transmitted if there is no body in the request.
The final part of the request is its body. Not all requests have one: requests fetching resources, like
HEAD, DELETE, or OPTIONS, usually don't need one. Some requests send data to the server in order to update it: as often the case with
POST requests (containing HTML form data).
Bodies can be broadly divided into two categories:
The start line of an HTTP response, called the status line, contains the following information:
A typical status line looks like:
HTTP/1.1 404 Not Found.
HTTP headers for responses follow the same structure as any other 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 its value, presents as a single line.
There are numerous response headers available. These can be divided into several groups:
Via, apply to the whole message.
Accept-Ranges, give additional information about the server which doesn't fit in the status line.
Content-Length, apply to the body of the request. Obviously no such headers are transmitted when there is no body in the request.
Bodies can be broadly divided into three categories:
HTTP/1.x messages have a few drawbacks for performance:
HTTP/2 introduces an extra step: it divides HTTP/1.x messages into frames which are embedded in a stream. Data and header frames are separated, this allows header compression. Several streams can be combined together, a process called multiplexing, allowing more efficient underlying TCP connections.
HTTP frames are now transparent to Web developers. This is an additional step in HTTP/2, between HTTP/1.1 messages and the underlying transport protocol. No changes are needed in the APIs used by Web developers to utilize HTTP frames; when available in both the browser and the server, HTTP/2 is switched on and used.
HTTP messages are the key in using HTTP; their structure is simple and they are highly extensible. The HTTP/2 framing mechanism adds a new intermediate layer between the HTTP/1.x syntax and the underlying transport protocol, without fundamentally modifying it: building upon proven mechanisms.
© 2005–2017 Mozilla Developer Network and individual contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.