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.

- 42,091
- 47
- 181
- 266

- 2,056
- 2
- 13
- 11
-
Why would you edit a question from 2009 if I may ask? – zmuci Nov 07 '18 at 14:36
-
2@zmuci For a better formatting? – Константин Ван Nov 08 '18 at 07:28
5 Answers
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.

- 224,562
- 31
- 268
- 324
-
1As 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? – Константин Ван Nov 08 '18 at 07:48
-
1New links: [3.3.1. Transfer-Encoding](https://tools.ietf.org/html/rfc7230#section-3.3.1) and [3.3.2. Content-Length](https://tools.ietf.org/html/rfc7230#section-3.3.2) – Alexis Wilke Dec 13 '18 at 09:26
-
12@bdonlan 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". – Vinicius de Almeida Dec 23 '19 at 10:55
-
@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. – crush Aug 28 '20 at 01:47
-
1@crush Agree about the verbs, but the case could be made for PUT "/users/{id}/enabled" and DELETE "/users/{id}/enabled". – Morten Haraldsen Aug 11 '21 at 12:36
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}

- 21,058
- 23
- 106
- 176
-
3Exactly 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. – Agoston Horvath Nov 22 '16 at 10:25
-
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 – Carmine Ingaldi Jan 31 '19 at 15:32
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;
-
1This is the clearest example of PUT vs POST I've ever read, though out of topic – digital illusion Jan 16 '18 at 14:35
-
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. – Paul Groke Aug 21 '20 at 20:47
-
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);`. – Paul Groke Aug 21 '20 at 20:53
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.

- 118,520
- 32
- 167
- 192
-
3
-
1PUT 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. – Imre Pühvel Aug 15 '18 at 12:32
-
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? – Luke Puplett Nov 07 '18 at 14:36
-
1So you don't have a single _empty file_ on your computer, do you? – Константин Ван Nov 08 '18 at 07:33
-
1
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

- 83
- 3