Skip to content
W3S101

HTTP Requests

HTTP - Requests

Section titled “HTTP - Requests”

An HTTP client initiates communication by sending an HTTP request to a server. This request message adheres to a specific format:

  • A Request-line
  • Zero or more Header fields (General, Request, Representation headers) followed by CRLF
  • An Empty line (CRLF) indicating the end of the header fields
  • Optionally, a Message-body
The Request-line has the following structure:
Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Let’s break down each part of the Request-Line.

Request Method

Section titled “Request Method”

The Request Method indicates the action to be performed on the resource identified by the Request-URI. Methods are case-sensitive and always uppercase. Common methods in HTTP/1.1 and later include:

S.N.MethodDescription
1GETRetrieves a representation of the specified resource. GET requests should only retrieve data and be idempotent and safe (no side effects on the server).
2HEADIdentical to GET, but the server MUST NOT return a message-body in the response. It’s used to retrieve meta-information (headers) about the resource without transferring the entire content. Idempotent and safe.
3POSTSubmits an entity to the specified resource, often causing a change in state or side effects on the server (e.g., creating a new resource, submitting form data, triggering a process). Not idempotent, not safe.
4PUTReplaces all current representations of the target resource with the request payload. If the resource does not exist, it MAY create it. Idempotent, but not safe.
5DELETERemoves the specified resource. Idempotent, but not safe.
6PATCHApplies partial modifications to a resource. Not necessarily idempotent (depends on the patch format and server logic), not safe.
7OPTIONSDescribes the communication options (e.g., allowed methods, CORS headers) for the target resource. Idempotent and safe.
8CONNECTEstablishes a tunnel to the server identified by the target resource. Primarily used by proxies to tunnel HTTPS traffic.
9TRACEPerforms a message loop-back test along the path to the target resource, useful for debugging. Can have security implications (XST - Cross-Site Tracing) and is often disabled.

Request-URI

Section titled “Request-URI”

The Request-URI (Uniform Resource Identifier) identifies the resource upon which to apply the request. It can take several forms:

Request-URI = "*" | absoluteURI | abs_path | authority
S.N.FormDescription
1Asterisk (*)Used with the OPTIONS method when the request does not apply to a particular resource but to the server itself (e.g., OPTIONS * HTTP/1.1).
2absoluteURIUsed when making a request to a proxy. The proxy forwards the request or serves it from cache (e.g., GET http://www.example.com/index.html HTTP/1.1 when sent to a proxy).
3abs_pathThe most common form, used for requests to an origin server. It’s the path component of the URL (e.g., /path/to/resource.html). If the path is empty, it MUST be given as ”/” (the server root). Example: GET /pub/WWW/TheProject.html HTTP/1.1 (requires a Host header).
4authorityUsed only by the CONNECT method (e.g., CONNECT www.example.com:443 HTTP/1.1).

Request Header Fields

Section titled “Request Header Fields”

Request header fields allow the client to pass additional information about the request and about the client itself to the server. These fields act as request modifiers. Common request headers include:

  • Host: Specifies the domain name of the server (required for HTTP/1.1).
  • User-Agent: Describes the client software making the request.
  • Accept: Informs the server about the types of media (MIME types) the client can process.
  • Accept-Language: Informs the server about the natural languages the client prefers.
  • Accept-Encoding: Informs the server about the content encodings (compressions) the client supports.
  • Authorization: Contains credentials for authenticating the client with the server (e.g., Basic <credentials>, Bearer <token>).
  • Content-Type: Indicates the media type of the request body (for POST, PUT, PATCH).
  • Content-Length: Indicates the size of the request body in bytes.
  • If-Modified-Since / If-None-Match: Used for conditional requests, often for caching.
  • Cookie: Sends previously stored cookies back to the server.

Custom headers (often prefixed with X- historically, though this is no longer recommended practice for new, non-standard headers) can also be used for specific application needs.

Request Message Examples

Section titled “Request Message Examples”

Example 1: GET request to fetch an HTML page

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/98.0.4758.102
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1


(No message body for GET)

Example 2: POST request with JSON data

POST /api/users HTTP/1.1
Host: api.example.com
User-Agent: MyApp/1.0
Content-Type: application/json; charset=utf-8
Content-Length: 55
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
Connection: keep-alive


{
  "username": "newUser",
  "email": "new@example.com"
}

Example 3: POST request with form data

POST /submit-form HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
Accept-Language: en-US
Connection: keep-alive


name=John+Doe&email=john%40example.com