CORS preflight failed: 405, “does not have HTTP ok status” and friends

Before some requests the browser asks the server for permission with an OPTIONS request. If that question gets a 405, a login page or a redirect, the real request is never sent.

What a preflight is

For a simple request (GET or POST with plain form or text bodies and no custom headers) the browser just sends it. Anything else, such as PUT/DELETE, a JSON Content-Type, or an Authorization header, triggers a preflight: an OPTIONS request asking whether the real one is allowed.

OPTIONS /api/items HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: authorization, content-type

The server must reply with a 2xx and matching headers:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 7200
Vary: Origin

If anything is wrong the browser shows a CORS error and your fetch rejects with TypeError: Failed to fetch. The start of the story is in the CORS errors guide; this page is about the preflight step.

The messages, decoded

Need a reminder of what each status means? Look up any HTTP status code.

The 405 and 401 traps

• 405 Method Not Allowed: the framework routes by method and you only defined PUT /api/items, so OPTIONS /api/items matches nothing. Many frameworks need a CORS middleware or an explicit OPTIONS route.
• 401 Unauthorized: preflights never carry your Authorization header or cookies, by design. If an auth middleware runs first, it rejects every preflight. Let OPTIONS through before auth.
• Proxies and gateways: a load balancer, API gateway or CDN rule may block OPTIONS or strip headers before your app sees it. curl from the next section shows who answers.

Test the preflight with curl

curl -si -X OPTIONS https://api.example.com/api/items \
  -H "Origin: https://app.example.com" \
  -H "Access-Control-Request-Method: PUT" \
  -H "Access-Control-Request-Headers: authorization, content-type"

You want a 204 (or 200) and the four Access-Control-Allow-* lines. A 301/302 with a Location means a redirect, so fix the URL (see redirects explained).

Answering preflights by stack

# nginx (inside the location that proxies the API)
if ($request_method = OPTIONS) {
    add_header Access-Control-Allow-Origin "https://app.example.com" always;
    add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE" always;
    add_header Access-Control-Allow-Headers "Authorization, Content-Type" always;
    add_header Access-Control-Max-Age 7200 always;
    return 204;
}

// Express: before routes and auth
const cors = require('cors');
app.use(cors({ origin: 'https://app.example.com', credentials: true }));
app.options('*', cors());   // Express 4; Express 5 answers preflights via app.use

# Flask
from flask_cors import CORS
CORS(app, origins=["https://app.example.com"], supports_credentials=True)

# FastAPI
from fastapi.middleware.cors import CORSMiddleware
app.add_middleware(CORSMiddleware, allow_origins=["https://app.example.com"],
                   allow_methods=["*"], allow_headers=["*"], allow_credentials=True)

Serverless functions: handle event.httpMethod === "OPTIONS" (or the platform’s equivalent) first and return 204 with the headers; also enable CORS on the gateway itself if it has a setting.

Or avoid the preflight

• Serve the page and API from the same origin (a reverse proxy rule such as /api on the same domain), so no CORS applies at all. In development, the dev server’s proxy option does this.
• Access-Control-Max-Age lets browsers cache the answer (Chrome caps it at 2 hours) so the extra request happens rarely.

Preflight passes but cookies still go missing? See CORS with credentials.

Questions

Published 4 November 2026.