CORS — What Is Actually Happening

// An origin is scheme + host + PORT. All three must match.
https://aicancode.org        vs  https://api.aicancode.org   // different
http://localhost:3000        vs  http://localhost:8000       // different
https://aicancode.org        vs  http://aicancode.org        // different

// Why it exists: you are logged into your bank. You visit a hostile
// page. Without the same-origin policy, its JavaScript could call
// the bank's API with your cookies attached and READ the response.
// The policy stops the reading.

// Note what it does NOT stop: the request being SENT. A cross-origin
// form POST still reaches the server with cookies attached — that is
// CSRF, and it is a separate problem with a separate fix.

// Not subject to CORS at all — these are cross-origin by design:
<img src="https://other.com/a.png">
<script src="https://cdn.com/lib.js">
<form action="https://other.com/submit" method="post">

// Subject to CORS: fetch, XMLHttpRequest, and anything else that
// lets JavaScript READ the response.

// A "simple" request goes straight out. It qualifies only if:
//   method is GET, HEAD or POST
//   AND the only headers set are a short safe list
//   AND Content-Type is one of:
//       text/plain, application/x-www-form-urlencoded, multipart/form-data

// So this is simple:
fetch('/api/problems')

// And this is NOT — application/json is not on the list:
fetch('/api/problems', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },   // triggers preflight
  body: JSON.stringify(data),
})
// Neither is any request with an Authorization header.

// For those, the browser first sends a PREFLIGHT:
OPTIONS /api/problems
Origin: https://aicancode.org
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, authorization

// The server must answer:
Access-Control-Allow-Origin: https://aicancode.org
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: content-type, authorization
Access-Control-Max-Age: 86400        // cache it, or every call pays twice

// Only then does the real request go. Two round trips per call
// without Max-Age — a real latency cost, not just noise.

// "No 'Access-Control-Allow-Origin' header is present"
//   -> The server did not send the header at all. Either CORS is not
//      configured, or the request 500'd BEFORE the CORS middleware
//      ran. Check the server logs before touching CORS config.

// "The 'Access-Control-Allow-Origin' header has a value
//  'http://localhost:3000' that is not equal to the supplied origin"
//   -> Configured, but for a different origin. Usually the deployed
//      URL was never added.

// "Response to preflight request doesn't pass access control check"
//   -> The OPTIONS request itself failed. Often the route only
//      handles POST, or auth middleware rejected the unauthenticated
//      OPTIONS. Preflights carry no credentials — never require auth
//      on them.

// "Request header field x-request-id is not allowed"
//   -> Add it to Access-Control-Allow-Headers.

// The two conclusions that follow from the mechanism:
//   1. curl succeeding proves nothing — curl has no origin and does
//      not enforce CORS. Only a browser does.
//   2. There is no frontend fix. Not a header you can set, not a
//      fetch option. The server allows it, or it does not.