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. Methods GET HEAD OPTIONS TRACE DELETE PUT POST PATCH CONNECT QUERY PRI Extension methods Method properties Safe Idempotent Cacheable When a server rejects a method Crawlers and methods General-purpose servers are required to support GET and HEAD . All other methods are optional. 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. The OPTIONS method queries the communication options available for a resource or the server. The response includes an Allow header listing supported methods. 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. The DELETE method removes the target resource and all of its representations from the server. The PUT method replaces the target resource with the request content. When no resource exists at the target URL , PUT creates one. 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. The PATCH method applies partial modifications to a resource. Unlike PUT , which replaces the entire resource, PATCH changes only the specified fields. The CONNECT method establishes a tunnel to the origin server identified by the request target. Commonly used for HTTPS connections through an HTTP proxy. 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. 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

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 . 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 Repeated request 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. 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, freshness information, and a Content-Location header matching the request URI . 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. Crawlers and methods Google's crawlers send GET and POST alongside HEAD , OPTIONS , PUT , PATCH , and DELETE . Per Google's search relations team, the five less common methods account for under 1.5% of all crawler requests, and JavaScript running during rendering initiates them. Method filters at the proxy reach crawler traffic alongside ordinary clients. Restricting OPTIONS or PATCH on paths serving a JavaScript application interferes with rendering, so method limits belong on endpoints kept out of the index. Indexing stays keyed to URLs reachable by GET . Content assembled behind a POST submission needs an equivalent address answering a plain GET to appear in search results. 405 responses on URLs intended for indexing remove those URLs in the same way as other 4xx codes. RFC 9110: HTTP Semantics -- Methods RFC 10008: The HTTP QUERY Method Search Engine Roundtable: Google Crawlers Send HEAD, OPTIONS, PUT, PATCH, DELETE HTTP status codes