In a Go net/http middleware, how do you recognise a CORS preflight request and answer it?

## What a preflight is, in terms of what arrives at your Go server Before a browser lets page JavaScript make certain cross-origin requests, it sends a separate, automatic request first and only issues the real one if the answer is satisfactory. That first request is the *preflight*. From the point of view of a Go server it is an ordinary inbound request with three distinguishing marks: - the method is `OPTIONS`; - there is an `Origin` request header naming the page's origin, e.g. `https://app.example.com`; - there is an `Access-Control-Request-Method` header naming the method the real request will use, and often an `Access-Control-Request-Headers` header listing the header names it will send. It has **no body**, **no cookies**, and none of the custom headers themselves — only their names. Your handler cannot authenticate it, log a user id for it, or read anything useful out of it. ## Why this is middleware code you write yourself The standard library has no CORS helper. `net/http` gives you the shape — a handler is anything with `ServeHTTP(http.ResponseWriter, *http.Request)`, and middleware is conventionally `func(http.Handler) http.Handler` — and you supply the policy. Because the preflight has no application meaning, it should be answered by the wrapper and never passed inward: the wrapper writes the response and *returns* instead of calling `next.ServeHTTP`. That is what "short-circuiting" means here, and it is the single most important structural fact about a CORS wrapper. ## The detection predicate The common mistake is to short-circuit on the method alone: ```go if r.Method == http.MethodOptions { /* answer 204 */ } ``` `OPTIONS` is a real method that clients send for other reasons, and a service may want to answer it itself. Testing both the method and the presence of `Access-Control-Request-Method` keeps the branch narrow: only a browser preflight sets that header, so only a browser preflight is swallowed. ```go isPreflight := r.Method == http.MethodOptions && r.Header.Get("Access-Control-Request-Method") != "" ``` `Header.Get` returns the empty string when the header is absent, so the `!= ""` test is the idiomatic presence check; there is no separate "has" method. ## What the preflight response must contain A preflight response is a status plus headers, with no body: - `Access-Control-Allow-Origin` — the allowed origin (see the sibling question on echoing it). Without this, nothing else matters. - `Access-Control-Allow-Methods` — the methods the real request may use. It is fine to answer with the whole set your API supports rather than reflecting the one method asked about. - `Access-Control-Allow-Headers` — the header names the real request may send, which must cover everything the browser listed in `Access-Control-Request-Headers`. - optionally `Access-Control-Allow-Credentials: true` when the real request will carry cookies, and `Access-Control-Max-Age` to let the browser reuse this answer for a while. Then `w.WriteHeader(http.StatusNoContent)` and `return`. 204 is the conventional status because there is no body; any 2xx works, and a non-2xx makes the browser treat the preflight as failed. This is why the wrapper must answer *before* anything that could reject the request on its own — a preflight that reaches an authentication check gets a 401, and the browser reports it to the frontend engineer as an opaque CORS error rather than as an auth problem. ## The non-preflight path Everything that is not a preflight — including the real request that follows it — falls through to `next.ServeHTTP(w, r)`. The browser re-checks `Access-Control-Allow-Origin` on *that* response too, so the origin headers belong outside the preflight branch, set on the way in, not only inside it. ## Mechanics worth knowing `w.Header()` returns the response header map; mutations to it only reach the wire if they happen **before** the first `WriteHeader` or `Write` call, because that is when `net/http` serialises the header block. Setting a CORS header after the inner handler has already written is a no-op. `Header.Set` replaces a value, `Header.Add` appends another — `Vary` is the header you normally `Add`, since another layer may already have contributed a value to it. ## Shape to remember Read the origin, set the origin headers, test for the preflight, answer 204 and return, otherwise call `next`. Four steps, and the ordering of the last two is where most hand-rolled CORS middleware goes wrong.