How the Browser Builds an HTTP Request

The browser builds an HTTP request by turning request intent into a structured message with a method, target, headers, optional body, and protocol-specific representation.

Learning Question

Once the browser has decided to make a request, what does it actually construct?

It constructs an HTTP request.

An HTTP request is not just a URL. It is a structured message that describes what the client is asking for, where the request is aimed within the server’s HTTP space, what metadata accompanies the request, and whether any body data is being sent.

The first mental model is:

The browser turns request intent into an HTTP message before lower network layers move its bytes.

The Main Parts of an HTTP Request

A simplified HTTP request has these conceptual parts:

Part	Role
Method	Describes the kind of request, such as GET, POST, PUT, PATCH, or DELETE.
Target	Identifies the requested path and query within the authority named by the URL.
Headers	Carry metadata about the request, client, accepted response forms, credentials, content type, caching, and other protocol concerns.
Body	Carries optional request data, such as JSON, form data, or uploaded file bytes.

For HTTP/1.1, a conceptual request might look like this:

POST /api/items HTTP/1.1
Host: example.com
Content-Type: application/json
Accept: application/json
 
{"name":"Notebook"}

This textual shape is useful for learning, but it is not the only real representation. HTTP/2 and HTTP/3 represent request information differently on the wire.

The durable point is:

HTTP defines structured request information. The exact byte representation depends on the HTTP version and transport.

The URL Is Split Into Roles

A URL such as this:

https://example.com:443/api/items?sort=recent

contains several pieces with different roles:

URL Part	Example	Role
Scheme	https	Says which kind of protocol and security behavior is expected.
Hostname	example.com	Names the remote authority that must be resolved to an address.
Port	443	Identifies the service endpoint on the remote machine or load balancer.
Path	/api/items	Identifies the HTTP resource or route target within the server’s HTTP space.
Query	sort=recent	Adds request parameters to the target.

The whole URL is not sent as one magic instruction to the server application.

The browser uses the scheme, host, and port to prepare network communication. It uses the path and query as the request target. It may use the host in headers or HTTP authority metadata.

Later, server-side routing may match the path to application code.

Method Is Not the Same as Server Action

The HTTP method describes request semantics at the protocol level.

Common examples:

• GET asks to retrieve a representation.
• POST sends data for server-side processing.
• PUT often sends a complete replacement representation.
• PATCH often sends a partial change.
• DELETE asks to delete or remove a resource.

The method does not itself execute a database operation.

A DELETE /items/1 request does not delete anything by crossing the network. It is a message asking the server to handle a delete-shaped request. The server application may authorize it, reject it, ignore it, translate it into a database change, or return an error.

The method describes the request. Application code implements the behavior.

Headers Are Protocol Metadata

Headers are key-value metadata attached to the request.

Examples include:

• Host: the authority being requested
• Accept: response media types the client can accept
• Content-Type: the format of the request body
• Authorization: credentials or tokens
• Cookie: cookies included with the request
• User-Agent: information about the client software
• Cache-Control: cache-related instructions

Headers are part of the message.

They are not separate function arguments passed through a language runtime. The server framework may later expose them through a request object, but they cross the network as protocol data.

Body Is Serialized Data

The request body carries bytes.

Those bytes may represent JSON:

{"name":"Notebook"}

They may represent form data:

email=a@example.com&password=...

They may represent multipart file upload data.

They may represent binary content.

The browser does not send a JavaScript object as a live object. It sends a serialized representation. The server may parse that representation into a server-side object, but that object is newly created inside the server runtime.

This is a key boundary:

Runtime objects do not cross the network. Serialized bytes do.

Browser-Controlled Additions

The application does not fully handcraft every byte of a browser request.

The browser may add, remove, block, or adjust request details according to web platform rules.

Examples include:

• adding cookies that match the request’s domain, path, security, and same-site rules
• adding or controlling headers such as Host
• setting content length or transfer-related details
• applying CORS preflight behavior when required
• following redirect policy
• deciding whether cached data can satisfy the request
• choosing HTTP/1.1, HTTP/2, or HTTP/3 according to connection negotiation and support

Client code describes the requested operation. The browser turns it into a valid web-platform request.

CORS Preflight as a Separate Request

Some cross-origin requests require the browser to send a preliminary request before the actual request.

This is often called a CORS preflight request. It commonly uses the OPTIONS method and asks whether the actual cross-origin request is allowed.

The important distinction is:

One application-level fetch call may cause more than one HTTP request.

If the preflight fails, the browser may never send the intended request.

From the server’s perspective, this means it may receive an OPTIONS request before the real method. That OPTIONS request is not the application data submission itself. It is part of the browser’s security model for cross-origin access.

Request Construction Is Not Routing

When the browser builds this request:

POST /api/items

it is not choosing a server function.

It is constructing a request target. The server’s routing logic may later map that method and path to a handler.

The route exists as server-side configuration or code. The request only carries data that the server can use for matching.

Therefore:

• the browser creates an HTTP request target
• the server interprets that target
• the framework or server code chooses the handler

Those steps happen in different execution contexts.

What This Chapter Does Not Explain Yet

This chapter explains the HTTP request as a structured message.

It does not yet explain how the hostname becomes an IP address.

It does not yet explain how TCP, TLS, QUIC, sockets, or packets carry the request.

It does not yet explain how the server process receives and parses the request.

Those are lower transport and server-side steps. The point here is that the browser has now created application-level request data that lower layers can transport.

Core Mental Model

Keep these parts separate:

• The URL identifies scheme, authority, path, query, and sometimes port.
• The method describes the kind of HTTP request.
• Headers carry protocol metadata.
• The body carries optional serialized data.
• Browser rules may add, block, or transform request details.
• Server routing happens later, after the request reaches server-side code.

The diagnostic question is:

Am I talking about the HTTP message the browser builds, or the server behavior that may later handle it?

Final Summary

The browser builds an HTTP request by formatting request intent into a structured protocol message.

That message contains method, target, headers, and optional body data. It is still not a server function call; it is the application-level message that lower networking layers will carry toward the server.