Allow

The HTTP Allow response header lists the HTTP Methods a target resource supports.

Table of Contents

Usage

Servers include Allow to communicate which request Methods a resource supports. The header is required in 405 Method Not Allowed responses, where the server informs the client about the valid methods for the requested URI.

The header also appears in responses to OPTIONS requests. An OPTIONS request asks the server to describe the communication options available for a resource, and Allow provides the list of permitted methods in the response.

The value is a comma-separated list of standard HTTP method names. The list reflects the methods the resource accepts at the time of the response. An empty Allow header signals no methods are currently accepted, which occurs when a server temporarily restricts access to a resource.

The Allow header describes the target resource, not the server as a whole. Different resources on the same server often support different sets of methods. A collection endpoint might accept GET and POST, while an individual resource supports GET, PUT, and DELETE.

Directives

method-list

A comma-separated list of HTTP method names. Common values include:

  • GET: retrieve the resource
  • HEAD: retrieve headers without a body
  • POST: submit data to the resource
  • PUT: replace the resource
  • PATCH: partially modify the resource
  • DELETE: remove the resource
  • OPTIONS: describe communication options
Allow: GET, HEAD, POST

Example

A client sends a DELETE request to a resource supporting only GET and POST. The server responds with 405 and includes the Allow header listing the valid methods.

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST
Content-Type: application/json

A response to an OPTIONS request shows all methods the resource accepts. The HEAD method is implicitly available when GET is supported.

HTTP/1.1 200 OK
Allow: GET, HEAD, PUT, DELETE
Content-Length: 0

A 201 Created response after a POST includes Allow to indicate the methods available on the newly created resource.

HTTP/1.1 201 Created
Location: /items/42
Allow: GET, PUT, DELETE

Where Allow goes missing

A 405 response is required to carry Allow, and the requirement is widely broken by infrastructure rather than applications. nginx never emits the header at all: no code path in the server sets an Allow field, so a 405 answered by nginx arrives bare. A missing Allow on a 405 usually identifies the proxy as the responder rather than the application behind.

Apache generates the header automatically, on OPTIONS responses, on 405, and on 501 as a non-required extra, building the list from the methods the resource supports and appending TRACE unless TraceEnable off removes support. Express answers OPTIONS with Allow and duplicates the list in the response body, while producing no 405 at all, letting unmatched methods fall through to the 404 handler.

An empty value is legal and meaningful: a resource allowing no methods, temporarily disabled by configuration, answers Allow: with nothing after the colon.

CORS middleware explains most other absences. An OPTIONS request handled as a preflight gets Access-Control-Allow-Methods and commonly no Allow, and the two are not interchangeable: one speaks to browsers enforcing cross-origin rules, the other to any client asking what a resource supports.

Caching separates the pair as well. OPTIONS responses are never cacheable, while a 405 is heuristically cacheable, so a stale cached Allow list arrives only through the error path.

See also

Last updated: August 17, 2026