Payloads of HTTP Request Methods

The Wikipedia entry on HTTP lists the following HTTP request methods:

• HEAD: Asks for the response identical to the one that would correspond to a GET request, but without the response body.
• GET: Requests a representation of the specified resource.
• POST: Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request.
• PUT: Uploads a representation of the specified resource.
• DELETE: Deletes the specified resource.
• TRACE: Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.
• OPTIONS: Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
• CONNECT: Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.
• PATCH: Is used to apply partial modifications to a resource.

I'm interested in knowing (specifically regarding the first five methods):

• which of these methods are able (supposed to?) receive payloads
  • of the methods that can receive payloads, how do they receive it?
    • via query string in URL?
    • via URL-encoded body?
    • via raw / chunked body?
    • via a combination of ([all / some] of) the above?

I appreciate all input, if you could share some (preferably light) reading that would be great too!

Solution 1:

Here is the summary from RFC 7231, an updated version of the link @Darrel posted:

• HEAD - No defined body semantics.
• GET - No defined body semantics.
• PUT - Body supported.
• POST - Body supported.
• DELETE - No defined body semantics.
• TRACE - Body not supported.
• OPTIONS - Body supported but no semantics on usage (maybe in the future).
• CONNECT - No defined body semantics

As @John also mentioned, all request methods support query strings in the URL (one notable exception might be OPTIONS which only seems to be useful [in my tests] if the URL is HOST/*).

I haven't tested the CONNECT and PATCH methods since I have no interest in them ATM.

Solution 2:

RFC 7231, HTTP 1.1 Semantics and Content, is the most up-to-date and authoritative source on the semantics of the HTTP methods. This spec says that there are no defined meaning for a payload that may be included in a GET, HEAD, OPTIONS, or CONNECT message. Section 4.3.8 says that the client must not send a body for a TRACE request. So, only TRACE cannot have a payload, but GET, HEAD, OPTIONS, and CONNECT probably won't and the server isn't expected to know how to handle it if the client sends one (meaning it can ignore it).

If you believe anything is ambiguous, then there is a mailing list where you can voice your concerns.

Solution 3:

I'm pretty sure it's not clear whether or not GET requests can have payloads. GET requests generally post form data through the query string, same for HEAD requests. HEAD is essentially GET - except it doesn't want a response body.

(Side note: I say it's not clear because a GET request could technically upgrade to another protocol; in fact, a version of websockets did just this, and while some proxy software worked fine with it, others chocked upon the handshake.)

POST generally has a body. Nothing is stopping you from using a query string, but the POST body will generally contain form data in a POST.

For more (and more detailed) information, I'd hit the actual HTTP/1.1 specs.