Allow general response

What it does

Allow lists the HTTP methods the server supports for the requested resource. It's mandatory on 405 Method Not Allowed responses — when a client tries an unsupported method, the server must tell them which methods are supported. It can also appear on 200 OK responses to OPTIONS requests as a resource capability advertisement.

Syntax

Allow: <method>[, <method>]*

Examples:

Allow: GET, HEAD
Allow: GET, POST, HEAD, OPTIONS
Allow: GET, HEAD, PUT, DELETE, OPTIONS
Allow: OPTIONS

Methods are comma-separated. Order is not significant.

When it's required

Mandatory on 405 Method Not Allowed. If a client sends DELETE /article/1 and that resource only supports GET and POST, the server must return:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST, HEAD, OPTIONS

Without Allow on a 405, the client has no way to know what methods are valid — they'd have to guess.

Optional on 200 OK responses to OPTIONS. The OPTIONS method is used to discover what methods a resource supports. Servers should respond with Allow listing supported methods:

OPTIONS /api/users/42 HTTP/1.1

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

Optional on other responses. Servers can include Allow on any response to advertise capabilities, but this is rare outside of 405 and OPTIONS contexts.

Allow and REST API design

Allow is central to well-designed REST APIs. Each resource (URL) has a specific set of supported methods — Allow makes this discoverable at runtime:

Good REST APIs return meaningful 405 responses with Allow instead of opaque 404s or 500s when a client tries the wrong method.

HEAD is almost always included

If a resource supports GET, it should also list HEAD. HTTP requires that HEAD responses be identical to GET responses minus the body — any server that supports GET implicitly supports HEAD. Omitting it from Allow is technically incorrect.

CORS preflight and Allow

In CORS preflight requests (OPTIONS with Access-Control-Request-Method), the browser is checking whether the actual method is allowed cross-origin. The Allow header is distinct from the CORS response headers (Access-Control-Allow-Methods) — they serve different purposes:

• Allow — what methods this resource supports at all
• Access-Control-Allow-Methods — what methods are permitted for cross-origin requests

A resource can support DELETE (listed in Allow) but not permit cross-origin DELETE (not in Access-Control-Allow-Methods). The two are independent.

Common mistakes and gotchas

Returning 404 instead of 405 for wrong methods. A very common API design mistake. If /users/42 exists but doesn't support DELETE, return 405 Method Not Allowed (with Allow), not 404 Not Found. 404 implies the resource doesn't exist; 405 implies it exists but the method is wrong.

Omitting Allow on 405 responses. This violates the spec and leaves clients with no way to know what to try instead. Always include it.

Not including OPTIONS in Allow. If your resource handles OPTIONS (which it should for CORS), include it in the Allow header. Some clients use OPTIONS to probe capabilities before making requests.

Real-world examples

405 on a read-only resource:

DELETE /api/articles/1 HTTP/1.1

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

{"error": "Method not allowed", "allowed": ["GET", "HEAD", "OPTIONS"]}

OPTIONS discovery:

OPTIONS /api/users/42 HTTP/1.1

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

Allow on a 200 for informational purposes:

HTTP/1.1 200 OK
Allow: GET, POST, HEAD, OPTIONS
Content-Type: application/json

FAQ

What's the difference between Allow and Access-Control-Allow-Methods?

Allow says what methods this resource supports in general. Access-Control-Allow-Methods says what methods cross-origin JavaScript is permitted to use. A resource might support POST (listed in Allow) but not allow cross-origin POST (not in Access-Control-Allow-Methods). They're independent controls.

Should Allow list every method, including ones that return errors?

No — Allow should list only methods that are meaningfully handled by the resource. If TRACE and CONNECT are disabled globally, don't list them. If a method would always return an error, don't list it. Allow is about genuine capability, not just "technically parseable."

Does Allow work for custom HTTP methods?

Yes — HTTP allows custom methods, and Allow can list them. Custom methods (beyond the standard GET, POST, PUT, DELETE, etc.) are uncommon but valid per spec. They're used in protocols like WebDAV (PROPFIND, MKCOL, COPY, MOVE).

Fun fact

The Allow header is one of the oldest in HTTP, present since HTTP/1.0 (1996). Yet it's consistently underimplemented — studies of real-world APIs routinely find that servers return 404 or 500 instead of 405 + Allow for wrong-method requests, making APIs harder to integrate without reading documentation. The WebDAV extension (RFC 4918, 2007) made heavy use of Allow for its expanded method set, which is why WebDAV servers tend to implement it more correctly than generic REST APIs.