Allow
The Allow response header lists all of the HTTP methods that may be used on the target resource, so that a client may select one understood by the server on subsequent requests. It is required in a 405 (Method Not Allowed)
response, and optional in other responses.
As a rule of thumb, any method not listed here will return 405 (Method Not Allowed) or 501 (Not Implemented)
, and listed methods will never return 404 (Not Found)
or 405 (but may return other errors, such as 401 (Unauthorized)
).
Writing responses (servers)
Servers should know which methods are valid on a given resource; all the different methods that the server logic can possibly execute. For each resource, the value of this header should always be the same (unless a security reason warrants otherwise).
This header must be sent in 405 (Method Not Allowed)
responses, and should also be sent in response to an OPTIONS request.
- GET, HEAD
- Always list these together, unless for some reason the resource exists without a readable representation (where a GET request would return 405).
- OPTIONS
- Servers should typically always support OPTIONS, and should list OPTIONS.
- PUT, PATCH
- List PUT if the resource can be modified (by any user, not necessarially by the current user). List PATCH if the server additionally supports the PATCH method.
- DELETE
- List DELETE if the resource supports a DELETE request.
- POST
- List POST if the resource has a defined POST handler.
In APIs, send this header in 2xx, 3xx, and 4xx responses; this describes the API so that clients can determine what sorts of actions they may perform on a resource after downloading it. By sending this header, clients can skip a potential re-request if they first make a request with an invalid method (e.g. if the client tries PATCH when the server only supports PUT, the client can know to avoid PATCH requests altogether instead of finding this out after a 405 (Method Not Allowed) response). If the resource does not exist but it can be created (i.e. in a 404 response), PUT should be the only method listed.
GET should always be accompanied by HEAD, since both must be supported at the same time.
Reading responses (clients)
Clients should read this header to determine the course of action for follow-up requests on the same resource.
If available, clients can read this header to determine how to write to a resource; if the resource indicates it supports PATCH, the client can send a patch; otherwise if it supports PUT, the client will need to upload the entire document.
RFC7231 seems to imply the OPTIONS method is always permitted, even if not listed in Allow.
Link relations
Some media types support a media-type-specific link attribute that functions similar to Allow, which lists the known permitted methods of the link target.
Overview table
- Name
- Allow
- Description
- Lists methods supported by the resource.
- Direction
- Response
- Advertises
- HTTP method
- Specification
- RFC 7231: HTTP/1.1 Semantics and Content ยง7.4.1. Allow
Syntax
Allow = #method
Examples
An example of a resource that is hard-coded or has been read off a read-only filesystem:
HTTP/1.1 200 OK
Date: Thu, 18 Apr 2019 00:07:32 GMT
Content-Type: application/xhtml+xml
Allow: GET, HEAD, OPTIONS