How a Client Action Becomes a Request Intent

A client action becomes a request intent when browser behavior or client-side code decides that new information or a state change must be requested from some network target.

Learning Question

When I click a button, submit a form, or load a page, how does that become the decision to send a request?

The user action itself is not the request.

A click is an input event. A form submission is browser behavior. A page load is a navigation. Client-side JavaScript may also decide to fetch data without a visible user action.

The request begins only after the browser or client runtime decides that communication with a network target is needed.

The first separation is:

A user action may cause request intent, but it is not itself a network request.

User Action Is Only the Visible Cause

A user action is something like:

• clicking a link
• clicking a button
• submitting a form
• typing into a search box that triggers autocomplete
• loading or refreshing a page
• scrolling to a point that triggers more data loading

These actions occur in the client environment.

They may lead to a request, but they do not contain the request. They produce input that the browser or application code responds to.

For example:

user clicks "Save"
-> browser dispatches a click event
-> JavaScript event handler runs
-> event handler decides whether to send a request

The browser event system is local client-side execution. No server code has run yet.

Built-In Browser Requests

Some requests are created by built-in browser behavior.

When the user enters a URL and presses Enter, the browser creates a navigation request.

When the browser parses an HTML page and sees linked resources, it may create additional requests:

• CSS files from <link rel="stylesheet">
• JavaScript files from <script src="...">
• images from <img src="...">
• fonts from CSS declarations
• iframes from <iframe src="...">

In these cases, JavaScript code in the page may not explicitly call fetch. The browser itself has rules that produce request intent from document loading and rendering needs.

The important point is:

The browser can create request intent from built-in web platform behavior, not only from application JavaScript.

JavaScript-Created Requests

Client-side JavaScript can also create request intent explicitly.

Examples include:

fetch("/api/items")

navigator.sendBeacon("/analytics", data)

const socket = new WebSocket("wss://example.com/events")

For a normal HTTP request, fetch does not directly send bytes itself as ordinary JavaScript code. It asks the browser’s networking implementation to perform a request according to web platform rules.

The JavaScript call is local.

The network request is browser-managed work that may happen because of that call.

Request Intent Is Not Yet an HTTP Message

Request intent is the decision that a request should be made.

At this point, the browser or client may know some high-level facts:

• the target URL
• the method, such as GET or POST
• request headers requested by the application or added by the browser
• body data, if any
• credentials mode, cache mode, redirect mode, and other client-side options

But intent is not yet the complete network transmission.

The browser still has to apply rules, resolve the target, enforce security restrictions, find or create a connection, format protocol data, and hand bytes to lower layers.

This distinction prevents an important confusion:

Calling fetch creates a request operation. It does not mean request bytes have already reached the server.

Client-Side Rules Before Sending

Before a request is sent, the browser may apply several rules.

Examples include:

• resolving relative URLs against the current page URL
• deciding whether cookies or credentials are included
• checking mixed-content rules, such as HTTPS pages trying to load insecure resources
• applying same-origin and CORS-related behavior
• consulting cache rules
• applying service worker interception when one is registered
• adding browser-controlled headers
• blocking forbidden headers that JavaScript is not allowed to set directly

These rules belong to the client side.

If the browser blocks a request before sending it, the server may never see anything.

If a service worker responds from cache, the network may not be used for that operation.

If the browser serves a cached response, no fresh request may reach the server.

Therefore, “my code called fetch” and “the server received a request” are different claims.

A Form Submission Example

Consider a simple form:

<form method="POST" action="/login">
  <input name="email">
  <input name="password" type="password">
  <button>Sign in</button>
</form>

When the user clicks the button, the browser does not call a server function named login.

The path is:

user clicks button
-> browser dispatches click and submit-related behavior
-> browser collects form fields
-> browser uses method="POST" and action="/login"
-> browser decides to create a navigation request
-> browser builds an HTTP request

The form’s action value becomes part of the request target. The form fields become request body data. The method tells the browser how to describe the request.

None of that gives the browser direct access to the server-side login function.

The server must later receive and route the request.

A Fetch Example

Consider a button handled by JavaScript:

button.addEventListener("click", async () => {
  const response = await fetch("/api/items", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ name: "Notebook" })
  });
 
  const item = await response.json();
  renderItem(item);
});

The click event handler runs in the browser.

The fetch call creates a request operation with a target, method, headers, and body.

JSON.stringify creates text. It does not send a JavaScript object across the network.

The browser later receives response bytes, parses the response body as JSON when response.json() is called, and creates a new JavaScript object in the client runtime.

The client-side object and the server-side object are separate runtime values connected only by serialized data.

What Does Not Happen Yet

At the request-intent stage:

• no server function has been called directly
• no server database has been queried by the browser
• no server memory has been accessed
• no response exists yet
• the request may still be blocked, cached, redirected, modified, or delayed by client-side rules

The intent is the starting point of request creation, not proof of server-side handling.

Core Mental Model

Keep these steps separate:

• A user action is local input.
• Browser behavior or JavaScript handles that input.
• The client decides whether it needs a network operation.
• Request intent describes what the client wants to ask for or submit.
• The browser still has to turn that intent into a protocol-formatted request.

The diagnostic question is:

Has a network request actually been sent, or has the client only decided that one should be made?

Final Summary

A client action becomes a web request only after browser behavior or client-side code turns that action into request intent.

The user action, JavaScript event handler, form behavior, and fetch call are still client-side execution. The server is involved only if the browser actually creates and sends a request that reaches a server process.