OPTIONS

When a client needs to determine which methods and capabilities a server supports, it sends an HTTP OPTIONS request.

Table of Contents

Usage

An OPTIONS request retrieves the allowed methods and capabilities of a target resource without performing an action on the resource. The server responds with an Allow header listing the supported methods.

When an asterisk (*) is used as the request target, the request applies to the server as a whole rather than a specific resource.

OPTIONS * HTTP/1.1
Host: api.example.re

CORS preflight

The most common real-world use of OPTIONS is the CORS preflight request. Before sending a cross-origin request with a method outside the CORS-safelisted set, custom headers, or a Content-Type outside the safelisted set (application/x-www-form-urlencoded, multipart/form-data, text/plain), the browser automatically sends an OPTIONS request to the target server. The preflight checks whether the server permits the actual request.

The preflight request includes Origin, Access-Control-Request-Method, and optionally Access-Control-Request-Headers. The server responds with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers to signal approval.

Properties

Property Value
Safe Yes
Idempotent Yes
Cacheable No

Example

Resource capabilities

A client queries the allowed methods for a specific resource. The server responds with 204 No Content and an Allow header.

Request

OPTIONS /articles HTTP/1.1
Host: api.example.re

Response

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD, POST, DELETE

Server-wide query

Using * as the target reveals the methods the server supports in general, independent of any specific resource.

Request

OPTIONS * HTTP/1.1
Host: api.example.re

Response

HTTP/1.1 204 No Content
Allow: OPTIONS, GET, HEAD

CORS preflight

A browser prepares a cross-origin PUT request with a custom X-Request-ID header. Before sending the actual request, the browser issues a preflight OPTIONS request to confirm the server allows the method and header from the requesting origin.

Preflight request

OPTIONS /api/data HTTP/1.1
Host: api.example.re
Origin: https://app.example.re
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Request-ID

Preflight response

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.re
Access-Control-Allow-Methods: GET, PUT, DELETE
Access-Control-Allow-Headers: X-Request-ID
Access-Control-Max-Age: 86400

The Access-Control-Max-Age value tells the browser to cache the preflight result for 86,400 seconds (one day), avoiding repeated preflight requests for the same endpoint.

Security

OPTIONS responses include an Allow header listing every method the resource supports. This is minor information disclosure, and security scanners often flag an enabled OPTIONS endpoint as a finding. Disabling OPTIONS entirely is not a practical solution because CORS preflight requests require OPTIONS to function.

The recommended approach is restricting the Allow header to only the methods each endpoint needs. A resource that accepts GET and POST should not advertise DELETE or PUT in the Allow list.

Some frameworks support an X-HTTP-Method-Override header to tunnel PUT, PATCH, or DELETE through a POST request. This bypasses method-based access controls and is a security concern if the feature is not explicitly enabled and audited.

To avoid unnecessary preflight requests, keep cross-origin requests within the "simple" request criteria: GET, HEAD, or POST with safelisted headers and safelisted content types only. Using Content-Type: application/json always triggers a preflight. Access-Control-Max-Age caches preflight results to reduce repeated OPTIONS round-trips.

See also

Last updated: April 4, 2026