Требуется ли HTTP-запрос PUT для включения тела?

Question

У меня проблемы с поиском определенной спецификации в стандарте. У меня есть HTTP-клиент, который не включает заголовок Content-Length: 0 при выполнении запроса PUT, когда я не указываю тело, и сервер, который запутывается такими запросами, и мне интересно, какую программу я должен винить.

Answer 1

HTTP-запросы имеют тело, если они имеют заголовок Content-Length или Transfer-Encoding ( RFC 2616 4.3 ). Если запрос не имеет ни того, ни другого, он не имеет тела, и ваш сервер должен обработать его как таковой.

Это сказало, что для запроса PUT необычно отсутствие тела, и поэтому, если бы я проектировал клиента, который действительно хотел бы отправить пустое тело, я бы передал Content-Length: 0. Действительно, в зависимости от чтения Из определений методов POST и PUT ( RFC 2616 9.5, 9.6 ) можно утверждать, что тело подразумевается как обязательное, но разумным способом обработки тела не должно быть тело нулевой длины.

Answer 2

Не отвечая на вопрос, но утверждая, что jaxrs позволяет мне часто использовать PUT без тела:

Пример безликого пута: Дайте пользователю дополнительное разрешение.

PUT / admin / users / {имя пользователя} / разрешение / {разрешение}

Answer 3

Тело не требуется стандартом IETF, хотя длина содержимого должна быть 0, если тела нет. Используйте метод, который подходит для того, что вы делаете. Если бы вы поместили это в код, дали

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

и удаленная переменная с именем r.

Сообщение эквивалентно

r=f();

Путь эквивалентен

r=x;

и получение эквивалентно

x=r;

Answer 4

Что означает PUT (в глагольном смысле) на сервер, если нет контента? spec относится к контенту как к «вложенной сущности», но запрос без контента не будет иметь вложенной сущности и, следовательно, ничего не помещать на сервер.

Если, конечно, вы не хотите ничего ПОСТАВЛЯТЬ на сервер, в этом случае вы, вероятно, захотите вместо этого УДАЛИТЬ.

Answer 5

Поле длины содержимого является обязательным согласно следующему разделу в стандарте HTTP / 1.1 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13