What does a typical HTTP request look like?

An HTTP request is just a series of lines of text that follow the HTTP protocol. A GET request might look like this:

GET /hello.txt HTTP/1.1

User-Agent : curl/7.36.0 lib.curl/7.63.0 OpenSSl/1.1.1 zlib/1.2.11

Host: www.example.com

Accept-Language: en

This section of text, generated by the user's browser, gets sent across the Internet. The problem is, it's sent just like this, in plaintext that anyone monitoring the connection can read. (Those who are unfamiliar with the HTTP protocol may find this text hard to understand, but anyone with baseline knowledge of the protocol's commands and syntax can read it easily.)

This is especially an issue when users submit sensitive data via a website or a web application. This could be a password, a credit card number, or any other data entered into a form, and in HTTP all this data is sent in plaintext for anyone to read. (When a user submits a form, the browser translates this into an HTTP POST request instead of an HTTP GET request.)

When an origin server receives an HTTP request, it sends an HTTP response, which is similar:

HTTP/1.1 200 OK

Date: Wed, 12 Jul 2022 12:14:39 GMT

Server: Apache

Last-Modified: Mon, 28 Jun 2022 11:17:01 GMT

Accept-Ranges: bytes

Content-Length: 12

Vary: Accept-Encoding

Content-Type: text/plain

Hello World!

If a website uses HTTP instead of HTTPS, all requests and responses can be read by anyone who is monitoring the session.

Essentially, a malicious actor can just read the text in the request or the response and know exactly what information someone is asking for, sending, or receiving. When consider with HTTPS, HTTPS uses TLS (or SSL) to encrypt HTTP requests and responses, so in the example above, instead of the text, an attacker would see a bunch of seemingly random characters. Instead of:

GET /hello.txt HTTP/1.1

User-Agent : curl/7.36.0 lib.curl/7.63.0 OpenSSl/1.1.1 zlib/1.2.11

Host: www.example.com

Accept-Language: en

The attacker sees something like:

t8FWo2kpuit0bbxiL1S3+pi9&jerlaSmK2

HTTP Messages

HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.

There are two types of HTTP messages, requests and responses, each with its own format.

Requests

Requests consist of the following elements:

• An HTTP method, usually a verb like GET, POST or a noun like OPTIONS or HEAD that defines the operation the client wants to perform. Typically, a client wants to etch a resource (using GET) or post the value of an HTML form (using POST), though more operations may be needed in other cases.

• The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the protocol (http://), the domain (here, google.com), or the TCP port.

• The version of the HTTP protocol.

• Optional headers that convey additional information for the servers.

• Or a body, for some methods like POST, similar to those in responses, which contain the resource sent.

Responses

Responses consist of the following elements:

• The version of the HTTP protocol they follow.

• A status code, indicating if the request was successful, or not, and why.

• A status message, a non-authoritative short description of the status code.

• HTTP headers like those for requests.

• Optionally, a body containing the fetched resource.

HTTP can use both nonpersistent connections and persistent connections. A nonpersistent connection is the one that is closed after the server sends the requested object to the client. In other words, the connection is used exactly for one request and one response.

With persistent connections, the server leaves the TCP connection open after sending responses and hence the subsequent requests and responses between the same client and server can be sent. The server closes the connection only when it is not used for a certain configurable amount of time.

With persistent connections, the performance is improved by 20%. A persistent connection takes 2 RTT for the connection and then transfers as many objects, as wanted, over this single connection.

Nonpersistent connections are the default mode for HTTP/1.0 and persistent connections are the default mode for HTTP/1.1. The non-persistent connection takes the connection time of 2RTT + file transmission time. It takes the first RTT (round-trip time) to establish the connection between the server and the client. The second RTT is taken to request and return the object. This case stands for a single object transmission.

HTTP Status Codes

HTTP response status codes indicate whether a specific HTTP request has been successfully completed. Responses are grouped in five classes:

1. Informational responses (100–199)

2. Successful responses (200–299)

3. . Redirects (300–399)

4. Client errors (400–499)

5. And Server errors (500–599).

1. Information responses

100 Continue : This interim response indicates that everything so far is OK and that the client should continue the request, or ignore the response if the request is already finished.

2. Successful responses

200 OK: The request has succeeded. The meaning of the success depends on the HTTP method:

• GET: The resource has been fetched and is transmitted in the message body.

• HEAD: The entity headers are in the message body.

• PUT or POST: The resource describing the result of the action is transmitted in the message body.

• TRACE: The message body contains the request message as received by the serve

3. Redirection messages

301 Moved Permanently: The URL of the requested resource has been changed permanently. The new URL is given in the response.

4. Client error responses

400 Bad Request: The server could not understand the request due to invalid syntax.

5. Server error responses

500 Internal Server Error: The server has encountered a situation it doesn't know how to handle