Look up any registered HTTP request method: what it does, which specification defines it, and whether it is safe and idempotent. The table covers the nine core methods and the WebDAV, DeltaV and CalDAV extensions.
Runs locally in your browserHTTP request methods state what a request is meant to do. Nine core methods come from HTTP itself — GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE and PATCH; the rest are registered extensions for WebDAV, versioning and calendaring, plus two methods that later HTTP revisions removed. The table lists every method in the IANA HTTP Method Registry with the specification that defines it and whether it is safe and idempotent.
| Method | Defined in | Safe / idempotent | Purpose |
|---|---|---|---|
| Core methods | |||
| GET | RFC 9110 §9.3.1 | yes / yes | Retrieve a representation of the target resource. |
| HEAD | RFC 9110 §9.3.2 | yes / yes | Retrieve the response headers without the response body. |
| POST | RFC 9110 §9.3.3 | no / no | Send data to the target resource for processing; often creates a resource or starts an action. |
| PUT | RFC 9110 §9.3.4 | no / yes | Create the target resource or replace it with the request content. |
| DELETE | RFC 9110 §9.3.5 | no / yes | Remove the target resource. |
| CONNECT | RFC 9110 §9.3.6 | no / no | Open a tunnel to the target authority, usually through a proxy. |
| OPTIONS | RFC 9110 §9.3.7 | yes / yes | Ask which methods and options the target resource supports. |
| TRACE | RFC 9110 §9.3.8 | yes / yes | Ask the server to echo the received request for diagnostics. |
| PATCH | RFC 5789 §2 | no / no | Apply the changes described in the request content to the target resource. |
| WebDAV extensions | |||
| PROPFIND | RFC 4918 §9.1 | yes / yes | Read the properties of a resource; the Depth header selects the tree. |
| PROPPATCH | RFC 4918 §9.2 | no / yes | Set or remove several properties of a resource in one request. |
| MKCOL | RFC 4918 §9.3 | no / yes | Create a collection, the folder-like resource of WebDAV. |
| COPY | RFC 4918 §9.8 | no / yes | Copy a resource to the URI given in the Destination header. |
| MOVE | RFC 4918 §9.9 | no / yes | Move a resource to the URI given in the Destination header. |
| LOCK | RFC 4918 §9.10 | no / no | Take a write lock on a resource and return a lock token. |
| UNLOCK | RFC 4918 §9.11 | no / yes | Release a lock with the token from the Lock-Token header. |
| ACL | RFC 3744 §8.1 | no / yes | Read or change the access control list of a resource. |
| SEARCH | RFC 5323 §2 | yes / yes | Run a DASL query over a collection and return the matching resources. |
| MKCALENDAR | RFC 4791 §5.3.1 | no / yes | Create a calendar collection with its calendar properties. |
| BIND | RFC 5842 §4 | no / yes | Add an existing resource to a collection as a new binding. |
| UNBIND | RFC 5842 §5 | no / yes | Remove a binding from a collection. |
| REBIND | RFC 5842 §6 | no / yes | Move a binding from one collection to another. |
| ORDERPATCH | RFC 3648 §7 | no / yes | Change the position of the members of an ordered collection. |
| MKREDIRECTREF | RFC 4437 §6 | no / yes | Create a redirect reference resource that points at another URI. |
| UPDATEREDIRECTREF | RFC 4437 §7 | no / yes | Change the target URI of a redirect reference resource. |
| Versioning extensions (DeltaV) | |||
| VERSION-CONTROL | RFC 3253 §3.5 | no / yes | Put a resource under version control. |
| REPORT | RFC 3253 §3.6 | yes / yes | Ask for a versioning, property or DAV report about a resource. |
| CHECKOUT | RFC 3253 §8.8 | no / yes | Make a version-controlled resource writable, or create a working resource. |
| CHECKIN | RFC 3253 §9.4 | no / yes | Save the changes as a new version and return the resource to read-only. |
| UNCHECKOUT | RFC 3253 §4.5 | no / yes | Cancel a checkout and discard the uncommitted changes. |
| MKWORKSPACE | RFC 3253 §6.3 | no / yes | Create a workspace for versioned work. |
| UPDATE | RFC 3253 §7.1 | no / yes | Apply the changes of one version to another resource. |
| LABEL | RFC 3253 §8.2 | no / yes | Add or remove a label on versions. |
| MERGE | RFC 3253 §11.2 | no / yes | Merge the differences between two version histories. |
| BASELINE-CONTROL | RFC 3253 §12.6 | no / yes | Turn a collection into a baseline-controlled collection. |
| MKACTIVITY | RFC 3253 §13.5 | no / yes | Create an activity that groups changes across resources. |
| Other registered methods | |||
| QUERY | RFC 10008 §2 | yes / yes | Send a safe, idempotent query with its parameters in the request content. |
| PRI | RFC 9113 §3.4 | yes / yes | Sent only in the HTTP/2 connection preface, before any frame. |
| Removed from HTTP | |||
| LINK | RFC 2068 §19.6.1.2 | no / yes | Defined in RFC 2068 to create a link between resources; later HTTP revisions removed it. |
| UNLINK | RFC 2068 §19.6.1.3 | no / yes | Defined in RFC 2068 to remove a link between resources; later HTTP revisions removed it. |
This page lists every method in the IANA HTTP Method Registry, the register the IETF keeps for HTTP request methods. Each row gives the method name, the specification that defines it, whether it is safe and idempotent, and one line on what it does.
The rows ship with the page: nothing is generated at runtime, no input is required, and no request is sent while you read. The search field only filters the table in your browser.
A method is safe when the specification defines it as read-only: GET, HEAD, OPTIONS, TRACE, PROPFIND, REPORT, SEARCH, QUERY and PRI are marked safe in the registry. Safe describes the intent, not the side effects a server chooses to add — a GET can still be logged, counted or billed.
A method is idempotent when repeating the identical request has the same effect as sending it once. PUT, DELETE and almost every WebDAV and DeltaV method are idempotent; POST, PATCH, CONNECT and LOCK are not, so a client or proxy must not repeat them automatically after a timeout.
The IANA registry is updated as new methods are published, and this table follows it: the method name, the safe and idempotent flags and the first specification listed. Where the registry records further specifications — MKCOL is extended by RFC 5689, PROPFIND and REPORT by RFC 8144 — the defining RFC is the one shown.
Methods outside the registry exist. UPnP SSDP sends M-SEARCH over UDP, RFC 2774 defines M- prefixed extension methods such as M-GET, and many APIs invent verbs of their own; a server that does not recognise a method answers 405 Method Not Allowed, and a proxy may refuse it outright.
LINK and UNLINK come from RFC 2068, the first HTTP/1.1 specification, and were removed later: the registry still lists them with their draft reference, but no current HTTP specification uses them.
PRI is sent once per connection, in the HTTP/2 connection preface, before any frame; the registry also lists the asterisk form, used as OPTIONS * to address the server as a whole instead of one resource. Both are easy to misread in a request log.