skipnothing/HTTP & Networking

CORS & Preflight

Your fetch('https://api.example.org/orders') comes back blocked, so you keep adding headers to the request and it keeps failing. The one header that unblocks it lives on the response, and only the server can send it.

  • ▸Add all the request headers you want, the read stays blocked until the server sends the one that names you.
  • ▸Change a POST's content type to JSON and the browser quietly sends a whole extra request before yours.
  • ▸Attach the user's credentials and the * that worked a second ago is suddenly rejected.
BUILDS ON
01

The Unlock Is on the Response

Start from where the last topic left off. Your page at https://app.example runs fetch('https://api.example.org/orders'). The server answers 200 with the JSON, but the browser refuses to hand your script the body, because the origins differ. The reflex is to fix it from your side: add an Authorization header, set Accept, retry. None of it moves the verdict, because none of it touches the thing the browser is actually checking.

The browser is reading the response for one header that names who is allowed to read it. If the server includes that header carrying your page's origin, https://app.example, the gate opens and your script reads the body. Leave it off, or return a different origin, and the read stays blocked. Same request, same 200, and the only thing that changed is a header the server chose to add on the way back.

That is the whole shift from the last topic. The client cannot unlock its own read, it is the party being restrained. Permission is granted on the response, by the one server that owns the data. You are not sending the key. You are waiting for the server to.

WHICH SIDE UNLOCKS THE READ

Keep going, sign up to unlock the rest

4 more parts in this topic, plus 23+ more topics in HTTP & Networking.

Sign up, it's freeSee the full HTTP & Networking