Some HTTP methods, such as POST
, require a body to be sent after the headers and the double CRLF
.
Others, such as GET
, do not have a body, and for them the double CRLF
marks the end of the request.
But what about others: PUT
, DELETE
, ... how to know which one requires a body?
How should a generic HTTP client react to an unknown HTTP method? Reject it? Require a body by default, or not require a body by default?
A pointer to the relevant spec would be appreciated.
Edit : I'll detail a bit more my question, as asked in the comments.
I'm designing a generic HTTP client that a programmer can use to send arbitrary HTTP requests to any server.
The client could be used like this (pseudo-code):
HttpClient.request(method, url [, data]);
The data is optional, and can be raw data (string), or an associative array of key/value pairs.
The library would url-encode the data if it's an array, then either append the data to the URL for a GET
request, or send it in the message body for a POST
request.
I'm therefore trying to determine whether this HttpClient must/should/must not/should not include a message-body in the request, given the HTTP method chosen by the developer.
HTTP request bodies are theoretically allowed for all methods except TRACE, however they are not commonly used except in PUT, POST and PATCH. Because of this, they may not be supported properly by some client frameworks, and you should not allow request bodies for GET, DELETE, TRACE, OPTIONS and HEAD methods.
Some HTTP methods, such as POST , require a body to be sent after the headers and the double CRLF . Others, such as GET , do not have a body, and for them the double CRLF marks the end of the request.
DELETE: Like its name, the Delete method deletes the server's representations of resources through the specific URL. Additionally, just like the Get method, they do not have a request body.
Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request.
EDIT: compiled list:
Content-Length
or Transfer-Encoding
header (section 4.3)For responses, this has been defined:
This (RFC 7231) Or This version (From IETF & More In-Depth) is what you want. According to the RFC:
For PUT
:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.
And for DELETE
:
The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
I'm going to answer this:
No request is required to include a body, although the absence of a body might be interpreted as an empty body or one of zero length.
RFC2616 4.3 states:
4.3 Message Body The rules for when a message-body is allowed in a message differ for requests and responses.
...
A message-body MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests.
Going through the methods in 5.1.1 (excluding any extension-methods) you will find:
9.8 TRACE
...
A TRACE request MUST NOT include an entity.
So technically any of the other request methods:
OPTIONS
GET
HEAD
POST
PUT
DELETE
CONNECT
... could include a body. Back to 4.3:
if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
So in-response to an unexpected entity-body for a particular method or resource, it is safe to ignore it and respond, including the response-code, as if the body was not sent.
Reference: RFC2616 Hypertext Transfer Protocol -- HTTP/1.1
Edit: RFC2616 is well and truly obsolete, refer to RFC7230 for the latest specification.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With