Access-Control-Request-Method

The HTTP Access-Control-Request-Method request header is sent by the browser during a CORS preflight to indicate which HTTP method the subsequent request will use.

Table of Contents

Usage

Before issuing a cross-origin request with a non-simple method, the browser sends a preflight OPTIONS request. The Access-Control-Request-Method header carries the intended method so the server decides whether to permit the call.

This header is mandatory in every preflight request. Preflight requests always use the OPTIONS method, which differs from the method the client plans to use, making the header necessary to communicate the real intent.

The server responds with Access-Control-Allow-Methods listing the methods the resource accepts. If the requested method does not appear in the response, the browser blocks the actual request.

Simple methods (GET, HEAD, and POST) do not always trigger a preflight. A preflight occurs when other factors demand the check, such as non-safelisted headers or a non-simple Content-Type value.

Example

A client-side application needs to update a resource using the PUT method. The browser sends a preflight with the intended method and a custom header.

Request

OPTIONS /api/resource/42 HTTP/1.1
Host: api.example.re
Origin: https://app.example.re
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: content-type

Response

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

A preflight for a DELETE request on a different resource.

Request

OPTIONS /api/resource/99 HTTP/1.1
Host: api.example.re
Origin: https://app.example.re
Access-Control-Request-Method: DELETE

One method, chosen by the browser

The header carries exactly one value, the method of the actual request, and script never writes the field: the Fetch standard lists the header among the forbidden names, so only the browser constructs a preflight. The preflight itself is always an OPTIONS request, which is the only place the header appears.

The wildcard interaction is the operational trap. An Access-Control-Allow-Methods: * answer satisfies the check only for requests without credentials. With credentials: "include", the wildcard counts as the literal character rather than a match-all, and the server has to name the method exactly. The same rule applies to the headers wildcard, and the combination explains authenticated requests failing preflight against servers answering * for everything.

Safelisted methods pass regardless. A GET, HEAD, or POST proceeds even where the allow list omits the method, so the check only ever bites methods outside the safelist.

Preflight results cache for five seconds by default where no Access-Control-Max-Age arrives, and browsers cap the maximum, so every uncached cross-origin PUT or DELETE costs an extra round trip.

See also

Last updated: August 17, 2026