Is an HTTP PUT request required to include a body?

Question

I'm having trouble finding a definite specification of this in the standard. I have an HTTP client that's not including a Content-Length: 0 header when doing a PUT request where I don't specify a body, and a server that gets confused by such requests, and I'm wondering which program I should be blaming.

Nippers

Why would you edit a question from 2009 if I may ask? – Sesquicarbonate

@Sesquicarbonate For a better formatting? – Beatnik

Answer 1

HTTP requests have a body if they have a Content-Length or Transfer-Encoding header (RFC 2616 4.3). If the request has neither, it has no body, and your server should treat it as such.

That said it is unusual for a PUT request to have no body, and so if I were designing a client that really wanted to send an empty body, I'd pass Content-Length: 0. Indeed, depending on one's reading of the POST and PUT method definitions (RFC 2616 9.5, 9.6) one might argue that the body is implied to be required - but a reasonable way to handle no body would be to assume a zero-length body.

Coburg

As HTTP status code 200 (“OK”), 201 (“Created”), and 204 (“No Content”) imply, a PUT request is basically for creating or updating a file on the server. And there's nothing illegitimate about a file being empty, isn't it? – Beatnik

New links: 3.3.1. Transfer-Encoding and 3.3.2. Content-Length – Resor

@Coburg you said that a PUT with an empty body is unusual, but if I want to enable or disable a user I will not need a body on my request, actually the PUT requests could be "/users/{id}/enable" or "/users/{id}/disable". – Pretentious

@ViniciusdeAlmeida Those resources wouldn't be appropriate if you are trying to adhere to REST standards. disable and enable are verbs. I'd probably prefer to use PATCH on the /users/{id} endpoint in that case. – Whish

@Whish Agree about the verbs, but the case could be made for PUT "/users/{id}/enabled" and DELETE "/users/{id}/enabled". – Luculent

Answer 2

Not answering the question, but asserting how jaxrs allows me to frequent use of bodyless PUTs:

Example of bodyless put: Give user an additional permission.

PUT /admin/users/{username}/permission/{permission}

Acrophobia

Exactly my problem! I came to the same conclusion. But strictly speaking, this goes against RFC, where, although not explicitly mentioned, body is referred to as existing. It could cause issues, but in my experience, all modern web servers/frameworks would work. – Stapes

I'm in a similar case, i need an API to associate an existing resource to a user. I could use a POST users/:userId/resources with resourceId in the body. Or rather it would fit a PUT users/:userid/resources/:resourceId. The big difference here is that the firt API is supposed to be non-idempotent, so i could associate same resource to a user twice. the PUT call should reset previous association – Woodrum

Answer 3

A body is not required by the IETF standard, though the content-length should be 0 if there's no body. Use the method that's appropriate for what you're doing. If you were to put it into code, given

int x;
int f(){ return x; }

and a remote variable called r.

A post is equivalent to

r=f();

A put is equivalent to

r=x;

and a get is equivalent to

x=r;

Anastrophe

This is the clearest example of PUT vs POST I've ever read, though out of topic – Synonym

If the request has a Content-Length header, then it has a body. It may be an empty body, but still a body. In contrast to a request with no Content-Length header, which has no body at all, not even an empty one. So yes, a PUT request, technically, strictly, has to have a body. Always. – Guardant

Also your POST analogy is totally confusing to me. If I try to stay with the rest of your analogy, it should be more like the server has an int f(int* resource, int body); and then POST would invoke f(&r, x); -- which may do or not do to r whatever the server thinks is appropriate. But it can also return stuff, so... maybe more like y = f(&r, x);. – Guardant

Answer 4

What is being PUT (in the verb sense) onto the server if there's no content? The spec refers to the content as "the enclosed entity", but a request with no content would have no enclosed entity, and therefore nothing to put on the server.

Unless, of course, you wanted to PUT nothing onto the server, in which case you'd probably want a DELETE instead.

Recommendatory

what your putting might be URL encoded rather than in the body – Pyroconductivity

PUT empty is just declaring that the resource with given identity must exist on server though it has no content besides the identity itself. Thats completely different semantics from DELETE. – Overestimate

Imagine you want to PUT a resource but accept all server-side defaults. That would be Content-Length: 0 or { } in JSON as the body? – Superstratum

So you don't have a single empty file on your computer, do you? – Beatnik

Does "enclosed entity" need to be in the body? – Acrophobia

Answer 5

The content length field is required as per the following section in the HTTP/1.1 standard http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13

Avert

That is a SHOULD not a MUST – Coburg