Payloads of HTTP Request Methods

Question

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!

Shanks

Answer 1

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.

Unlicensed

I still have to read it in more detail but it seems that the HTTPBis draft goes into the kind of details I was hoping to know. Thanks! – Shanks

I'm not sure about "most authoritative", since they're still drafts that are subject to change. Still, I agree that they are useful to clarify ambiguities in RFC 2616. – Crashland

FYI: RFC 7231 is obsoleted by RFC 9110. However, not sure whether it changes semantics though. – Depression

Section about TRACE is now 9.3.8 and still contains the "MUST NOT send content" part in it at the end. – Depression

Answer 2

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.

Shanks

OPTIONS takes the same set of URIs as any other method, and then applies to that resource. It's only special for "*". – Dinadinah

Could Connect have a payload? – Mansuetude

@CMCDragonkai: "Bodies on CONNECT requests have no defined semantics. Note that sending a body on a CONNECT request might cause some existing implementations to reject the request". – Shanks

@AlixAxel could you add the missing WebDAV verbs to the list? It's not exhaustive enough to be the accepted answer yet. – Rus

Isn't the body mandatory in a PUT request? It is supposed to encapsulate a resource full representation that will replace the resource at the given URI. – Fussy

Answer 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.

Handshaker

When I say payload I'm also referring to the data that carries out in the URL as a query string. I know that POST expects payloads via URL-encoded body and/or URL query string. GET supports payloads via URL query string and I think the same happens with both HEAD and DELETE but I'm not 100% sure about this. I read section 9 of the HTTP/1.1 RFC but it doesn't seem very clear to me. – Shanks

It's not entirely clear whether or not DELETE requests can have a body. However, nothing in the HTTP/1.1 RFC forbids it. And, well, a query string can be in any request, not just GET, HEAD and DELETE - the fact that form data is posted to body in POST and query string in GET may be more HTML related than anything. – Handshaker

It is spelled out quite clearly in Httpbis what it means to send a body in a DELETE tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#page-20 It doesn't mean anything and some existing internet components may reject it. Same goes for GET. – Unlicensed

@Darrel Miller: Oh okay, I didn't know that. – Handshaker

The objective of the Httpbis spec is to clarify the stuff that RFC2616 forgot to say or did not say well. – Unlicensed