Archit Sharma

Posted on Oct 30

HTTP Request and Response explained

#http #beginners #webdev #security

In this article we will take a look at general overview of the HTTP messages.

NOTE: The HTTP message formats, methods, and semantics described in this article are based on the official IETF specifications defined in RFC 9110

HTTP is a stateless protocol where clients and servers exchange HTTP messages through a simple request-response cycle. A client initiates by sending a request (containing a method, target, headers, and optional content). A server replies with a response (containing a status code, headers, and optional content).

You don't need to build HTTP messages by hand. Tools like your browser or a web server are programmed to create them correctly. Developers just use APIs and configuration files to control what those messages contain.

While each HTTP version has its own message format, this article uses HTTP/1.1 messages for readability for all HTTP messages.

HTTP Request

An HTTP request message has following four components mentioned below:

A Request-line: <Method> <Request-Target> <Protocol-Version>
Header (General|Request|Entity) fields followed by CRLF
An empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields
Optionally a message-body

Let's explore each component of an HTTP request message in detail:

Request Line

The start-line in HTTP/1.x requests is called a "request-line" and is made of three parts:

1. Method

The request method (like GET or POST) specifies the client's intention for the request and what a successful response should accomplish.

The following table lists all the supported methods in HTTP:

Method Name	Description
GET	The GET method is used to retrieve information from the given server using a given URI.
HEAD	Same as GET, but it transfers the status line and the header section only.
POST	A POST request is used to send data to the server
PUT	PUT updates a resource by replacing all of its data with the new content sent in the request.
DELETE	Removes the target resource entirely.
CONNECT	Sets up a direct network tunnel to a remote server, usually through a proxy. This is primarily used to establish HTTPS connections through a proxy.
OPTIONS	Retrieves the HTTP methods and other communication options that the server supports for the target resource.
TRACE	Performs a loop-back diagnostic test. The server echoes the received request message back to the client, allowing inspection of any modifications made by intermediaries along the path.

2. Request target

Request target is used to identify which resource the client wants to interact with. The format of the request target (usually a URL) is determined by both the HTTP method being requested and whether the request is to a proxy

Following are the most commonly used forms of targets:

Method	Description
Origin form	The most common form of Request target, consisting of the path and optional query string: `origin-form = absolute-path [ "?" query ]` When contacting a server directly, clients must send only the path and query from the full URL. The domain is sent separately in the `Host` header. Example: For `http://www.example.org/where?q=now`, the request is: `GET /where?q=now HTTP/1.1`
Absolute form	The absolute-form is used when sending requests through a proxy. Instead of just the path, the client sends the complete URL as the request target. Example: `GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1`
Authority form	The authority form is the host and port separated by a colon (:). It is only used with the `CONNECT` method when setting up an HTTP tunnel. Example: `CONNECT www.example.com:80 HTTP/1.1`
Asterisk form	The asterisk-form uses just * and is used only with the `OPTIONS` method to ask about the server’s overall capabilities, not any specific resource. Example: `OPTIONS * HTTP/1.1`

3. Protocol Version

Protocol Version in a request is a declaration made by the client indicating both the syntax format of the message being sent and the highest level of protocol features the client can understand for future communication from the server.

Learn more about HTTP Versions

Request Header Fields

Request Header fields allow the client to pass additional information (metadata) about the request, and about the client itself, to the server.

The format of an HTTP/1.x header is straightforward: a case-insensitive name, a colon (:), and then a value. The entire header field must fit on a single line.

Example of Request Header:

Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 49

NOTE: A detailed explanation of HTTP headers and their various types will be covered in upcoming articles.

Request body

The Request Body (content) is the part of an HTTP request that carries data from the client to the server. Only PATCH, POST, and PUT requests have a body.
The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field.

HTTP Response

An HTTP response message has following four components:

A Status-line: <HTTP-Version> <Status-Code> <Reason-Phrase>
Header (General|Response|Entity) fields
An empty line indicating the end of the header fields
Optionally a message-body

Status line

The first response line is the status-line, containing: protocol version, status code, and an optional reason phrase, each separated by spaces.
Example:

HTTP/1.1 200 OK

Detailed breakdown:

1. HTTP Version

HTTP Version or Protocol Version in a HTTP Response tells the client which set of protocol rules the server follows.
The "HTTP" in the HTTP-version is case-sensitive and must be written in uppercase. HTTP uses a major.minor numbering system, defined in RFC 9112.

2. Status Code

A status code is a three-digit number (from 100 to 599) that describes the result of an HTTP request. Only the first digit of a status code defines its class, while the last two digits have no categorization role.
There are five possible class values:

Status Code	Description
1xx (Informational)	It means the request was received and the process is continuing.
2xx (Success)	The request was successfully received, understood, and accepted
3xx (Redirection)	Further action needs to be taken in order to complete the request
4xx (Client Error)	The request contains bad syntax or cannot be fulfilled
5xx (Server Error)	The server failed to fulfill an apparently valid request

A list of all the status codes can be found in RFC 9110.

3. Reason phrase

Following the status code is an optional reason phrase, a human-readable description like Created, which explains the outcome. Its optional nature is sometimes shown with parentheses.

Response headers

Response headers are metadata sent with a response. In HTTP/1.x, each is a case-insensitive string followed by a colon (:) and a value, whose format is header-specific.