RFC XXXX: Additional HTTP Request Methods

Network Working Group
Request for Comments: XXXX
Category: Informational
Version: 1.1

Additional HTTP Request Methods

#Status of This Memo

This document specifies twelve additional HTTP request methods intended to extend the method set defined in RFC 7231. It is published for informational purposes and does not represent an Internet standard.

#Copyright Notice

This document is placed in the public domain (CC0 1.0 Universal). No rights reserved.

#Abstract

RFC 7231 defines eight request methods for the Hypertext Transfer Protocol: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, and TRACE. This document defines twelve supplementary methods addressing use cases not directly covered by the existing set, including rate-limit-exempt retrieval, resource liveness signaling, unconditional deletion, best-effort submission, generative summarization, and body-bearing retrieval. Methods are presented in alphabetical order.

       Status of This Memo
       Copyright Notice
       Abstract
   1.  Introduction
   2.  Conventions Used in This Document
   3.  Method Definitions
       3.1.   BORROW
       3.2.   BUMP
       3.3.   GHOST
       3.4.   HAUL
       3.5.   MAYBE
       3.6.   PEEK
       3.7.   RETRY
       3.8.   SHRUG
       3.9.   SQUINT
       3.10.  SUP
       3.11.  VIBE
       3.12.  YEET
   4.  Method Properties Summary
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
   8.  Changelog

1. Introduction#

The HTTP method set defined in RFC 7231 assumes a client that knows, at the time of request, precisely what outcome it wants and is prepared to accept the standard safety and idempotency semantics associated with that outcome. This document defines twelve additional methods for scenarios that fall outside those assumptions: exploratory or degraded retrieval, best-effort or provisional submission, unconditional removal, resource-state signaling, and body-bearing queries.

Each method definition specifies its semantics, its safety and idempotency properties, and example request and response messages. Implementers should treat this document as informational; none of the methods described here are registered with IANA.

2. Conventions Used in This Document#

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.

The terms "safe" and "idempotent" are used as defined in RFC 7231, Section 4.2.

3. Method Definitions#

3.1. BORROW#

BORROW retrieves a representation of the target resource, with semantics otherwise identical to GET, and additionally signals to the server that the client intends to submit a corresponding PUT request at a later time to return the resource to its original or an updated state.

BORROW is safe in the sense that it does not itself alter server state. It does not create an enforceable lock or reservation on the resource; concurrent modification by other clients remains possible and is outside the scope of this method.

Request:

    BORROW /resources/42 HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 200 OK
    X-Expected-Return: unspecified

    {"id": 42, "name": "widget"}

3.2. BUMP#

BUMP submits a request to the target resource for the sole purpose of updating server-side liveness or activity metadata (for example, a last-accessed or last-touched timestamp). No representation data is created or modified as a result of a BUMP request.

BUMP is neither safe nor idempotent, since repeated requests produce a distinct metadata update on each invocation, though the visible resource state remains otherwise unchanged.

Request:

    BUMP /resources/42 HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 200 OK

    {"id": 42, "last_touched": "2026-07-17T14:03:00Z"}

3.3. GHOST#

GHOST transmits a request to the server without the client establishing an expectation of, or waiting for, a response. The client MAY close the underlying connection before the server has completed processing.

GHOST is neither safe nor idempotent. Servers MAY process GHOST requests to completion regardless of client disconnection, but MUST NOT assume the client will receive or act on any resulting response.

Request:

    GHOST /notifications HTTP/1.1
    Host: example.com

Response:

    (none; the client does not wait for one)

3.4. HAUL#

HAUL retrieves a representation of the target resource using query parameters carried in the request body rather than the request URI. HAUL is intended for cases where the query is too large or too structurally complex to encode in a URI within practical length limits.

HAUL has semantics equivalent to GET and MUST be treated as safe and idempotent by servers and intermediaries. This method corresponds to the QUERY method proposed in the IETF HTTPQUERY draft.

Request:

    HAUL /resources HTTP/1.1
    Host: example.com
    Content-Type: application/json

    {
      "filter": {
        "status": ["active", "pending"],
        "created_after": "2026-01-01"
      },
      "sort": [{"field": "created_at", "order": "desc"}],
      "limit": 50
    }

Response:

    HTTP/1.1 200 OK
    Content-Type: application/json

    {"results": [ ... ], "total": 214}

3.5. MAYBE#

MAYBE submits data to the target resource with semantics otherwise identical to POST, except that the server retains discretion to discard the request without processing it, subject to server-defined criteria (for example, current load, rate limiting, or heuristic filtering).

MAYBE is neither safe nor idempotent. Clients MUST NOT rely on a MAYBE request having a guaranteed effect and SHOULD use POST instead when reliable submission is required.

Request:

    MAYBE /orders HTTP/1.1
    Host: example.com
    Content-Type: application/json

    {"item": "widget", "quantity": 3}

Response (request accepted):

    HTTP/1.1 204 No Content

Response (request discarded):

    (no response is returned)

3.6. PEEK#

PEEK retrieves a representation of the target resource with semantics otherwise identical to GET, and additionally signals to the server that the request should be exempted from applicable rate limiting.

PEEK is safe and idempotent. Servers are under no obligation to honor the rate-limit exemption and MAY apply standard rate limiting to PEEK requests as they would to GET requests.

Request:

    PEEK /resources/42 HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 429 Too Many Requests
    Retry-After: 60

3.7. RETRY#

RETRY submits data to the target resource with semantics otherwise identical to POST, and additionally signals to the server that this request follows one or more prior failed attempts to submit the same data.

RETRY is neither safe nor idempotent. Servers MAY use the retry signal to prioritize processing, apply deduplication logic, or return a cached result of a previous successful attempt with the same idempotency key.

Request:

    RETRY /payments HTTP/1.1
    Host: example.com
    X-Attempt-Number: 3

Response:

    HTTP/1.1 202 Accepted

    {"status": "queued", "attempt": 3}

3.8. SHRUG#

SHRUG performs a partial modification of the target resource, in the manner of PATCH, containing an empty change set. The result is that resource metadata such as a last-modified timestamp is updated without any change to the resource's field values.

SHRUG is not safe, since it modifies resource metadata, but is idempotent, since repeated invocations produce the same resulting state aside from the timestamp value.

Request:

    SHRUG /resources/42 HTTP/1.1
    Host: example.com
    Content-Type: application/merge-patch+json

    {}

Response:

    HTTP/1.1 200 OK

    {"id": 42, "updated_at": "2026-07-17T14:03:00Z"}

3.9. SQUINT#

SQUINT retrieves a reduced-fidelity representation of the target resource, with semantics otherwise identical to GET. The response omits or compresses fields at the server's discretion, intended for clients with constrained bandwidth or display capability.

SQUINT is safe and idempotent.

Request:

    SQUINT /resources/42 HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 200 OK
    Content-Type: application/reduced+json

    {"id": 42, "name": "widget"}

3.10. SUP#

SUP retrieves a summary status indicator for the target resource, distinct from its full representation. The response is intended to convey operational or availability state in condensed form, suitable for health checks or dashboard display.

SUP is safe and idempotent.

Request:

    SUP /services/example-service HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 200 OK
    Content-Type: text/plain

    operational

3.11. VIBE#

VIBE retrieves a generated natural-language summary of the target resource, produced by a language model rather than derived directly from the resource's stored representation.

VIBE is safe and idempotent with respect to server state, but its response content is not guaranteed to be accurate, complete, or reproducible between requests. Servers implementing VIBE SHOULD label responses with a content type that identifies them as generated content, and clients MUST NOT treat VIBE responses as authoritative.

Request:

    VIBE /services/example-service HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 200 OK
    Content-Type: text/generated

    The example-service appears to be running, probably. It was
    definitely doing something last Tuesday. Overall the vibes
    are neutral to positive, though this may change.

3.12. YEET#

YEET performs an unconditional deletion of the target resource, with semantics otherwise identical to DELETE, except that the request bypasses any confirmation, soft-delete, or recovery mechanism the server would ordinarily apply.

YEET is idempotent, in that repeated requests against an already-deleted resource leave the resource in the same deleted state, though servers MAY return different status codes on subsequent requests. YEET is not safe.

Request:

    YEET /resources/42 HTTP/1.1
    Host: example.com

Response:

    HTTP/1.1 410 Gone

4. Method Properties Summary#

Method	Safe	Idempotent	Cacheable
BORROW	Yes	Yes	No
BUMP	No	No	No
HAUL	Yes	Yes	Yes
GHOST	No	No	No
MAYBE	No	No	No
PEEK	Yes	Yes	Yes
RETRY	No	No	No
SHRUG	No	Yes	No
SQUINT	Yes	Yes	Yes
SUP	Yes	Yes	No
VIBE	Yes	Yes	No
YEET	No	Yes	No

5. Security Considerations#

YEET's bypass of confirmation and recovery mechanisms increases the risk of unintended, unrecoverable data loss relative to DELETE. Implementers should require additional authentication or authorization checks before honoring YEET requests.

MAYBE's nondeterministic acceptance behavior could be leveraged by an attacker to obscure the origin or timing of a successful malicious submission among a series of apparently discarded requests. Servers implementing MAYBE should log all received requests regardless of whether they are processed.

GHOST requests provide no delivery confirmation to the client and are therefore unsuitable for any operation requiring reliability or auditability guarantees.

VIBE responses are generated content and are not derived directly from authoritative resource state. Servers MUST NOT allow VIBE output to be cached or served in place of a GET response. Clients that log, store, or act on VIBE output should treat it as unverified.

HAUL carries a request body on what is semantically a retrieval operation; intermediaries that do not expect a body on GET-like methods may handle HAUL incorrectly. Implementers should consult the IETF HTTPQUERY draft for handling guidance.

6. IANA Considerations#

This document does not request any IANA actions. None of the methods defined herein are registered in the HTTP Method Registry.

7. References#

[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[HTTPQUERY] IETF HTTPBIS Working Group, "The QUERY Method for HTTP", Internet-Draft, work in progress.

8. Changelog#

2026-07-22 — v1.1: Corrected BORROW and VIBE idempotency classification in Section 4 properties table. Added missing response example for RETRY (Section 3.7). Clarified VIBE response example to better reflect non-authoritative generated output.

Twelve new HTTP methods for scenarios the original eight never anticipated.

#Status of This Memo

#Copyright Notice

#Abstract

Table of Contents

1. Introduction#

2. Conventions Used in This Document#

3. Method Definitions#

3.1. BORROW#

Request:

Response:

3.2. BUMP#

Request:

Response:

3.3. GHOST#

Request:

Response:

3.4. HAUL#

Request:

Response:

3.5. MAYBE#

Request:

Response (request accepted):

Response (request discarded):

3.6. PEEK#

Request:

Response:

3.7. RETRY#

Request:

Response:

3.8. SHRUG#

Request:

Response:

3.9. SQUINT#

Request:

Response:

3.10. SUP#

Request:

Response:

3.11. VIBE#

Request:

Response:

3.12. YEET#

Request:

Response:

4. Method Properties Summary#

5. Security Considerations#

6. IANA Considerations#

7. References#

8. Changelog#