Question

某些HTTP方法（例如POST）需要在标头和双CRLF之后发送正文。

其他人，例如GET，没有正文，对于他们来说，双CRLF标记了请求的结束。

但是其他人呢PUT，DELETE，...如何知道哪一个需要身体？

通用HTTP客户端应如何对未知的HTTP方法做出反应？拒绝吗？默认情况下需要正文，或者默认情况下不需要正文？

赞赏指向相关规范的指针。

修改：正如评论中所述，我将详细介绍我的问题。

我正在设计一个通用的HTTP 客户端，程序员可以使用它来向任何服务器发送任意HTTP请求。

客户端可以像这样使用（伪代码）：

HttpClient.request(method, url [, data]);

数据是可选的，可以是原始数据（字符串），也可以是键/值对的关联数组。

如果数据是数组，则库将对数据进行url编码，然后将数据附加到GET请求的URL，或者将其发送到消息正文中以获取POST请求。< / p>

因此，考虑到开发人员选择的HTTP方法，我正在尝试确定此HttpClient是否必须/不应该/不应该在请求中包含消息体。

Answer 1

编辑：汇编列表：

entity-body 仅在存在 message-body 时出现（第7.2节）
通过包含Content-Length或Transfer-Encoding标题（第4.3节）来表示存在消息正文
当请求方法的规范不允许发送 entity-body 时，不得包含 message-body （第4.3节）
仅在TRACE请求中明确禁止 entity-body ，所有其他请求类型不受限制（第9节和第9.节）

对于回复，已定义：

是否包含 message-body 取决于请求方法和响应状态（第4.3节）
在对HEAD请求的响应中明确禁止 message-body （具体为第9节和第9.4节）
在1xx（信息），204（无内容）和304（未修改）响应中明确禁止 message-body （第4.3节）
所有其他回复都包含一个消息体，尽管它可能是零长度（第4.3节）

This（RFC 7231）或This版本（来自IETF＆amp; More In-Depth）就是您想要的。根据RFC：

PUT：

PUT方法请求将所包含的实体存储在提供了Request-URI。如果Request-URI引用已存在的URI 资源，封闭的实体应该被视为修改过的驻留在源服务器上的版本。如果是Request-URI 不指向现有资源，并且该URI能够被请求用户代理定义为新资源 origin服务器可以使用该URI创建资源。如果是新资源创建后，源服务器必须通过201通知用户代理（创建）响应。如果修改了现有资源，则为应该发送200（OK）或204（No Content）响应代码以指示成功完成请求。如果资源不能使用Request-URI创建或修改了一个适当的错误应该给出反映问题性质的回应。该实体的接收者绝不能忽略任何Content- *（例如它不理解或实现的内容范围标题在这种情况下必须返回501（未实现）响应。

对于DELETE：

DELETE方法请求源服务器删除资源   由Request-URI标识。这种方法可以被人类覆盖   原始服务器上的干预（或其他方式）。客户不能   保证操作已经进行，即使是   从原始服务器返回的状态代码表示该操作   已成功完成。但是，服务器不应该   表示成功，除非在给出答复时，它打算成功   删除资源或将其移至无法访问的位置。

如果响应包含一个，那么成功的响应应该是200（OK）   描述状态的实体，202（已接受），如果操作尚未执行   已经颁布，或者如果行动已经颁布，则为204（无内容）   响应不包括实体。

如果请求通过缓存并且Request-URI标识   一个或多个当前缓存的实体，应该对这些条目进行处理   陈旧的。对此方法的响应不可缓存。

Answer 2

从您的评论中我得到的是您正在编写HTTP客户端库（为什么，还不够？）并且您希望允许使用通用request(method, url[, data])方法。您想知道method data是必需的还是禁止的。{/ p>

假设你的图书馆用户知道他们在做什么。如果我想发送一个带有GET请求的正文，我可以，因为规范并不禁止。那么为什么你的图书馆呢？

此外，HTTP规范在此开放; HTTP的扩展（如WebDAV）可以指定允许或不允许甚至需要消息体的新方法（动词）。

我认为目前的努力可以更好地用在更重要的部分上。

Answer 3

我要回答这个问题：

从请求主体而不是响应主体的角度来看，这是所要问的，并且是最感兴趣的。
关于何时需要尸体以及何时禁止。

不需要包含一个主体，尽管没有主体可能被解释为空主体或零长度之一。

RFC2616 4.3状态：

4.3邮件正文何时在消息中允许消息正文的规则有所不同请求和响应。

...

如果请求方法的规范（第5.1.1节）不允许在请求中发送实体，则消息正文不得包含在请求中。

遍历5.1.1中的方法（不包括任何扩展方法），您会发现：

9.8跟踪

...

TRACE请求不得包含实体。

从技术上讲，其他任何请求方法都可以：

OPTIONS
GET
HEAD
POST
PUT
DELETE
CONNECT

...可能包括身体。返回4.3：

如果请求方法不包含实体的定义语义，则处理请求时，应忽略消息正文。

因此，对于特定方法或资源对意外的实体主体做出响应，可以将其忽略并进行响应（包括响应代码），就像未发送主体一样。

参考：RFC2616 Hypertext Transfer Protocol -- HTTP/1.1

编辑： RFC2616确实过时了，有关最新规范，请参考RFC7230。

Answer 4

对于任意方法，或者您不希望在服务器端HTTP Status Code 405支持的有效方法应该发送回调用者。

根据http://en.wikipedia.org/wiki/List_of_HTTP_status_codes：

405不允许的方法使用a对资源进行了请求该资源不支持请求方法; [2]例如，使用在需要通过POST或使用的数据呈现数据的表单上获取 PUT在只读资源上。

Answer 5

您可能需要阅读有关邮件正文长度的当前HTTP规范草案部分：http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-22.html#message.body.length

哪种HTTP方法需要正文？

5 个答案: