Preflight requests behavior in Express - Step-by-Step Execution

Concept Flow - Preflight requests behavior

Browser sends OPTIONS request

↓

Server receives OPTIONS request

↓

Server checks CORS headers

↓

Browser sends actual request

↓

Server processes actual request

The browser first sends an OPTIONS request to check permissions. The server responds with CORS headers if allowed. Then the browser sends the real request.

Execution Sample

Express

app.options('/data', (req, res) => {
  res.set('Access-Control-Allow-Origin', '*');
  res.set('Access-Control-Allow-Methods', 'GET,POST');
  res.sendStatus(200);
});

This code handles the preflight OPTIONS request by sending CORS headers and a 200 OK status.

Execution Table

Step	Request Type	Server Action	Response Headers Sent	Browser Action
1	OPTIONS (Preflight)	Check if CORS allowed for origin and method	Access-Control-Allow-Origin: *; Access-Control-Allow-Methods: GET,POST	If allowed, proceed to send actual request
2	GET (Actual request)	Process GET request normally	Access-Control-Allow-Origin: *	Render or use response data
3	POST (Actual request)	Process POST request normally	Access-Control-Allow-Origin: *	Render or use response data
4	OPTIONS (Preflight)	If CORS not allowed, respond without CORS headers	No CORS headers	Block actual request, show error
5	Actual request	Blocked by browser due to failed preflight	No response	Request fails, error shown

💡 Execution stops when browser blocks actual request due to missing or invalid CORS headers in preflight response.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5
Request Type	None	OPTIONS	GET	POST	OPTIONS	Actual request blocked
Server Response Headers	None	CORS headers sent	CORS headers sent	CORS headers sent	No CORS headers	No response
Browser State	Idle	Preflight sent	Actual request sent	Actual request sent	Preflight failed	Request blocked

Key Moments - 3 Insights

Why does the browser send an OPTIONS request before the actual request?

The browser sends OPTIONS to check if the server allows the actual request's method and origin via CORS headers, as shown in execution_table step 1.

What happens if the server does not send CORS headers in response to the OPTIONS request?

The browser blocks the actual request because the preflight failed, as shown in execution_table steps 4 and 5.

Are CORS headers required on the actual GET or POST responses?

Yes, the server must send Access-Control-Allow-Origin on actual responses to allow the browser to accept them, as shown in execution_table steps 2 and 3.

Visual Quiz - 3 Questions

Look at the execution_table, what response headers does the server send during the OPTIONS preflight request when CORS is allowed?

A Access-Control-Allow-Origin: *; Access-Control-Allow-Methods: GET,POST

B No headers sent

C Access-Control-Allow-Origin: none

D Content-Type: application/json

💡 Hint

Check execution_table row 1 under 'Response Headers Sent'

At which step does the browser block the actual request due to failed preflight?

A Step 2

B Step 5

C Step 3

D Step 1

💡 Hint

Look at execution_table rows 4 and 5 for blocked requests

If the server sends CORS headers only on the OPTIONS request but not on the actual GET request, what will happen?

A Browser accepts the GET response normally

B Browser retries the OPTIONS request

C Browser blocks the GET response

D Browser ignores CORS and proceeds

💡 Hint

Refer to key_moments about CORS headers on actual responses and execution_table steps 2 and 3

Concept Snapshot

Preflight requests are OPTIONS requests browsers send before actual requests to check CORS permissions.
Server must respond with Access-Control-Allow-Origin and Access-Control-Allow-Methods headers.
If allowed, browser sends actual request; otherwise, it blocks it.
CORS headers must be present on both preflight and actual responses.
This protects users by enforcing cross-origin security rules.

Full Transcript

When a browser wants to send a cross-origin request that is not simple, it first sends an OPTIONS request called a preflight. This preflight asks the server if the actual request is allowed by checking CORS headers. The server responds with headers like Access-Control-Allow-Origin and Access-Control-Allow-Methods if it permits the request. If the browser sees these headers, it proceeds to send the real request (GET, POST, etc.). If the server does not send these headers, the browser blocks the actual request to protect the user. The server must also send Access-Control-Allow-Origin on the actual response for the browser to accept it. This process ensures safe cross-origin communication.