What is the HTTP OPTIONS method for, what does the Allow response header contain, and what does the request line `OPTIONS * HTTP/1.1` mean?

## The purpose of OPTIONS `OPTIONS` requests information about the communication options available for a target — a self-describing "what is possible here?" probe. It is *safe* (no state change) and *idempotent*. Unlike most methods it is about the interaction itself rather than about transferring a representation, and consequently its responses are **not cacheable by default**. A typical exchange returns `204 No Content`, or `200 OK` with an explicit `Content-Length: 0`. The `Content-Length: 0` matters on HTTP/1.1: without a body-framing header the client cannot tell where the response ends, so servers that return 200 for OPTIONS must state a zero length. ## The Allow header `Allow` is a **response** header listing the request methods supported by the target resource, comma-separated: `Allow: GET, HEAD, OPTIONS, PUT, DELETE`. Two rules are worth memorising: 1. `Allow` is the natural payload of an OPTIONS response. 2. `Allow` is **mandatory** on a `405 Method Not Allowed` response. When a server rejects a method it must tell the client which methods the resource does accept. Servers that return a bare 405 with no `Allow` are non-conforming, and this is a favourite interview gotcha. An empty `Allow:` header is meaningful and legal — it says the resource supports no methods at all. Do not confuse `Allow` with `Access-Control-Allow-Methods`. The first is HTTP's own method-advertisement header; the second belongs to the CORS layer and is only meaningful to a browser evaluating a cross-origin request. ## The asterisk form HTTP request-targets normally take *origin-form* (`OPTIONS /orders HTTP/1.1` plus a `Host` header) or, to a proxy, *absolute-form* (`OPTIONS http://example.com/orders HTTP/1.1`). OPTIONS additionally licenses **asterisk-form**: ``` OPTIONS * HTTP/1.1 Host: example.com ``` The `*` means "the server as a whole, not any particular resource". It is used to ask about general server capabilities, or simply to ping a server or a chain of proxies without touching application code. It is the only method for which `*` is a valid target. In HTTP/2 and HTTP/3 there is no request line, so this is expressed as `:path` set to `*` with `:method: OPTIONS`. A client wanting to probe the *next-hop proxy* rather than the origin sends `OPTIONS * ` with `Max-Forwards: 0`, which stops the request at the first intermediary. ## Where OPTIONS actually shows up In day-to-day engineering, hand-written OPTIONS discovery is rare — API consumers read documentation or a machine-readable schema, not `Allow` headers. The method's real-world volume comes from the **CORS preflight**: before a browser sends a cross-origin request that is not a simple one (custom headers, `PUT`/`DELETE`, a JSON content type), it first issues an OPTIONS request carrying `Origin`, `Access-Control-Request-Method`, and `Access-Control-Request-Headers`, and expects the matching `Access-Control-Allow-*` headers back. That preflight is a browser mechanism layered on OPTIONS; the underlying method semantics are the ones described above. Other appearances: WebDAV servers answer OPTIONS with `DAV:` capability headers; some load balancers and proxies use `OPTIONS *` as a cheap liveness probe; and API gateways often auto-generate OPTIONS handlers so preflights never reach application code. ## Operational and security considerations Because OPTIONS advertises capability, it also discloses it. Returning `Allow: GET, POST, PUT, DELETE, TRACE, PROPFIND` on a public endpoint hands a scanner a map of what to try, and tells it your server has methods enabled that you probably did not intend. The sensible posture is default-deny at the edge — enable only the methods the application actually implements — and let `Allow` reflect that reduced set honestly rather than lying about it. A second operational point: preflight OPTIONS requests must be answered fast and must not require authentication. Browsers do not send credentials on a preflight, so an auth filter that challenges OPTIONS with `401` breaks every cross-origin call. Similarly, rate limiters and WAFs that count or block OPTIONS aggressively can silently break a single-page application while the underlying API looks healthy. Finally, remember what OPTIONS does *not* do: it does not tell you what a method will do to a specific resource, what body shape it expects, or what authorisation you hold. It is a coarse method list, which is exactly why the industry standardised on schema documents instead.