HTTP Methods

HTTP methods (also called HTTP verbs) define the action a client requests on a server-side resource. Eleven methods cover the core operations of retrieval, modification, deletion, and metadata, and the IANA method registry extends the list with methods drawn from WebDAV and related protocols. Each method has properties (safe, idempotent, or cacheable) affecting how clients, servers, and intermediaries handle the request.

Table of Contents

Methods

Method Safe Idempotent Cacheable
GET X X Yes
HEAD X X Yes
OPTIONS X X No
TRACE X X No
DELETE X No, invalidates cache
PUT X No, invalidates cache
POST Conditional
PATCH Conditional
CONNECT No
PRI X X No
QUERY X X Yes

General-purpose servers are required to support GET and HEAD. All other methods are optional.

GET

The GET method retrieves the current representation of a resource. This is the primary retrieval mechanism and the most common HTTP method.

The HEAD method is identical to GET except the server returns only the status line and Headers, with no message body. Useful for checking resource existence or metadata without transferring the full content.

OPTIONS

The OPTIONS method queries the communication options available for a resource or the server. The response includes an Allow header listing supported methods.

TRACE

The TRACE method performs a loop-back test along the path to a resource. The server echoes the received request back to the client, useful for diagnosing intermediary modifications.

DELETE

The DELETE method removes the target resource and all of its representations from the server.

PUT

The PUT method replaces the target resource with the request content. When no resource exists at the target URL, PUT creates one.

POST

The POST method submits data to a resource for processing. The server determines the action: creating a new resource, updating an existing one, or triggering a side effect.

PATCH

The PATCH method applies partial modifications to a resource. Unlike PUT, which replaces the entire resource, PATCH changes only the specified fields.

CONNECT

The CONNECT method establishes a tunnel to the origin server identified by the request target. Commonly used for HTTPS connections through an HTTP proxy.

QUERY

The QUERY method sends a safe, idempotent query in the request body. QUERY combines the safety of GET with the ability to include a request body, suitable for complex queries exceeding practical URI length limits. QUERY became a Proposed Standard in June 2026.

PRI

The PRI method is the HTTP/2 connection preface method, sent as the first bytes of every HTTP/2 connection to signal protocol upgrade. PRI is not intended for use by clients or servers as a regular HTTP method.

Extension methods

The core methods carry ordinary web traffic, and protocols built on HTTP register further methods for their own operations. Servers advertise the methods a resource accepts through the Allow header.

WebDAV contributes the largest group. PROPFIND and PROPPATCH read and write resource properties, MKCOL creates collections, COPY and MOVE relocate resources, and LOCK and UNLOCK manage write access. Calendar scheduling and version control extensions register further methods on the same foundation. All of them travel over ordinary HTTP and reach the same servers as GET and POST.

Cache infrastructure runs unofficial methods outside any registry. Varnish and Squid accept PURGE to evict a single stored object, and Varnish adds BAN for removing groups of objects by pattern. Support for both depends entirely on the proxy configuration in front of the origin, so an identical request succeeds against one deployment and returns 405 against another.

Method properties

Safe

A safe method does not modify server state. The operation is read-only from the server's perspective. Side effects like logging or incrementing a counter do not change the safety classification, as the client did not request those effects.

Safe methods: GET, HEAD, OPTIONS, TRACE, QUERY, and PRI.

Idempotent

An idempotent method produces the same server state whether called once or multiple times. After the first request completes, repeating the same request has no additional effect.

All safe methods are idempotent. DELETE and PUT are also idempotent but not safe because they intentionally change server state.

Initial request

DELETE /documents/old-news HTTP/1.1
Host: www.example.re

Response

HTTP/1.1 200 OK

Repeated request

DELETE /documents/old-news HTTP/1.1
Host: www.example.re

Response

HTTP/1.1 404 Not Found

The response differs because the resource was already removed. The server state after both requests is identical: the resource is gone. This makes DELETE idempotent.

Cacheable

A cacheable method produces a response eligible for storage and reuse by caches. Cached responses avoid repeated transfers of identical data from the server.

GET and HEAD responses are cacheable by default. POST and PATCH responses are cacheable when the response includes explicit Cache-Control directives and freshness information.

Unsafe methods like PUT and DELETE invalidate cached entries for the target resource. A locally cached GET response becomes stale after a PUT to the same URL.

When a server rejects a method

A server rejecting a method returns 405 when the resource exists and accepts other methods, and 501 when the server implements no handling for the method anywhere. The distinction locates the problem: 405 points at the resource, 501 points at the server.

Every 405 response carries an Allow header listing the methods the resource accepts, which lets a client correct the request in one step. Responses arriving without the header leave the client probing method by method.

Reverse proxies filter methods before a request reaches the application. nginx restricts methods with limit_except, and Apache uses <LimitExcept>. A method working in local development and failing in production usually points at proxy configuration rather than application code.

Cross-origin requests using methods beyond GET, HEAD, and POST trigger a CORS preflight. The browser sends OPTIONS first, and the response needs Access-Control-Allow-Methods listing the intended method. Preflight failures surface in the browser as blocked requests rather than as 405 responses, which sends debugging toward the wrong layer.

See also

Last updated: August 17, 2026