Returning 204 vs 200 for OPTIONS Requests

The console error that starts most of these investigations:

Access to fetch at 'https://api.nimbusgrid.com/v1/exports' from origin
'https://studio.nimbusgrid.com' has been blocked by CORS policy: Response to
preflight request doesn't pass access control check: It does not have HTTP ok
status.

Root Cause

That message is not a verdict on 204 versus 200. The Fetch algorithm requires the preflight response to carry an ok status — anything from 200 to 299 — before it will read the Access-Control-* headers, and both candidates are inside that range. The error appears when the OPTIONS request reached something that answered 401, 403, 404, 405 or 500: an authentication filter, a router with no OPTIONS route, or a framework that rejects the method before any CORS logic runs. Swapping 204 for 200 will not fix it, and a surprising amount of time gets burned trying.

The real decision between the two statuses is made below the CORS layer, by HTTP framing rules, by proxy configuration that keys on status, and by CDN cache policy. This page sits under OPTIONS Endpoint Design for CORS Preflights, which covers the routing and header set of the endpoint itself; here the subject is only the status line and the bytes that may follow it.

Prerequisite State

• The OPTIONS route is reachable without authentication, so the status you see is the one your CORS handler chose rather than the one your auth filter chose.
• Exactly one layer answers preflights for the path. Two layers answering produces duplicated headers regardless of status.
• You can run curl against both the public hostname and the origin server, so you can tell a gateway’s answer from your application’s.
• The Access-Control-Allow-Origin, -Methods and -Headers values are already correct for the route.

Step-by-Step

Step 1 — See what is actually on the wire

Before changing anything, look at the response line and the framing headers together:

curl -sS -D - -o /dev/null -X OPTIONS https://api.nimbusgrid.com/v1/exports \
  -H 'Origin: https://studio.nimbusgrid.com' \
  -H 'Access-Control-Request-Method: POST' \
  -H 'Access-Control-Request-Headers: content-type'

A correct preflight and a subtly broken one differ by two lines that are easy to skim past:

Step 2 — Return 204 with nothing after the headers

204 is the default answer because it states exactly what happened: the request was understood, permission is described in the headers, and there is nothing to represent. In Express, use .end() rather than a send helper, so no serialiser gets a chance to attach a body:

const express = require("express");
const app = express();

app.options(/^\/v1\//, (req, res) => {
  if (req.headers.origin !== "https://studio.nimbusgrid.com") {
    return res.status(403).end();
  }
  res.set({
    "Access-Control-Allow-Origin": "https://studio.nimbusgrid.com",
    "Access-Control-Allow-Methods": "GET, POST, PUT, DELETE, OPTIONS",
    "Access-Control-Allow-Headers": "Authorization, Content-Type",
    "Access-Control-Max-Age": "600",
    "Vary": "Origin",
  });
  return res.status(204).end(); // no body, no Content-Type, no Content-Length
});

In Nginx the same answer is a single directive, and the always flag matters even here — without it, add_header applies only to a fixed list of statuses, so the day someone changes return 204 to return 202 the headers silently disappear:

location /v1/ {
    if ($request_method = OPTIONS) {
        add_header Access-Control-Allow-Origin  "https://studio.nimbusgrid.com" always;
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
        add_header Access-Control-Allow-Headers "Authorization, Content-Type" always;
        add_header Access-Control-Max-Age       "600" always;
        add_header Vary                         "Origin" always;
        return 204;
    }
    proxy_pass http://exports_upstream;
}

Spring MVC expresses it through ResponseEntity, which builds a genuinely bodiless response:

@RestController
public class PreflightController {

    @RequestMapping(value = "/v1/**", method = RequestMethod.OPTIONS)
    public ResponseEntity<Void> preflight() {
        return ResponseEntity.noContent()
                .header("Access-Control-Allow-Origin", "https://studio.nimbusgrid.com")
                .header("Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS")
                .header("Access-Control-Allow-Headers", "Authorization, Content-Type")
                .header("Access-Control-Max-Age", "600")
                .header("Vary", "Origin")
                .build();
    }
}

Step 3 — Check the status survives the layers in front of it

The preflight response passes through several consumers before the CORS check ever runs, and each one treats the status differently:

Whichever status you choose, keep Vary: Origin on the response or a shared cache will hand one origin’s grant to another — the mechanics are in Handling Vary: Origin Header Correctly.

Step 4 — Scope the 200 exception, do not globalise it

200 earns its place when something in the chain is not a browser: an old XHR wrapper that treats an empty response as a failure, a corporate proxy that strips bodiless responses, or a managed gateway whose generated integration returns 200 and cannot be changed. Confine the exception to the route that needs it:

const cors = require("cors");

// Only this partner-facing route answers 200; everything else keeps 204.
app.use(
  "/v1/legacy-partner",
  cors({
    origin: "https://studio.nimbusgrid.com",
    methods: ["GET", "POST", "OPTIONS"],
    allowedHeaders: ["Authorization", "Content-Type"],
    maxAge: 600,
    optionsSuccessStatus: 200,
  })
);

The choice, end to end:

Step 5 — Keep the two statuses out of the same path

The one configuration that is always wrong is a path where the status depends on which layer answered — an edge worker returning 204 on a cache miss and a gateway integration returning 200 on a hit, for example. The CORS headers usually differ too, so the failure is intermittent and origin-specific. Pick the owning layer, delete the other handler, and re-test through the public hostname; the same discipline is applied to edge termination in Handling CORS Preflight in Cloudflare Workers and to managed gateways in Configuring CORS Preflight in AWS API Gateway.

Verification

curl -sS -o /dev/null -w 'status=%{http_code} bytes=%{size_download}\n' \
  -X OPTIONS https://api.nimbusgrid.com/v1/exports \
  -H 'Origin: https://studio.nimbusgrid.com' \
  -H 'Access-Control-Request-Method: POST'

• status=204 (or the documented 200) and bytes=0
• No content-length above zero and no content-type on a 204 response
• access-control-allow-origin, -methods and -headers are all present on the chosen status
• The same command against the origin server returns the same status as the public hostname
• In DevTools → Network, the preflight row shows the expected status and a zero-byte response
• The real POST immediately after the preflight reuses the connection instead of opening a new one
• A deliberately unknown origin gets no Access-Control-* headers, whichever status is returned
• Repeating the call inside the Access-Control-Max-Age window sends no second OPTIONS

Security Boundary Note

A success status is not permission. Returning 204 to every OPTIONS request regardless of the Origin value is fine — and is often the cleanest design, because the browser blocks the real request when the headers are absent — but only if the headers really are absent for unknown origins. What must never happen is a handler that answers 204 with a reflected origin before the allowlist check, on the theory that a bodiless response is harmless: that grant is exactly what an attacker’s page needs, and pairing it with Access-Control-Allow-Credentials: true exposes authenticated data. Equally, do not let a permissive preflight paper over an authentication failure on the real method; the preflight must never be the place where authorisation is decided.

Common Mistakes

FAQ