哪种HTTP方法需要正文？

Question

某些HTTP方法(例如POST,需要在标题和double之后发送正文)CRLF.

其他人,例如GET,没有身体,对他们而言,双重CRLF标志着请求的结束.

但对于其他人:PUT,DELETE...怎么知道哪一个需要的身体吗？

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

可以理解指向相关规范的指针.

---

编辑:正如评论中所述,我将详细介绍我的问题.

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

客户端可以像这样使用(伪代码):

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

数据是可选的,可以是原始数据(字符串),也可以是键/值对的关联数组.

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

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

Answer 1

编辑:编译清单:

• 一个实体主体是仅当存在时一个消息体存在(第7.2部分)
• 通过包含a 或标题来表示消息体的存在(第4.3节)Content-LengthTransfer-Encoding
• 一个消息体必须不被包括在所述请求的方法的规范不允许发送实体主体(第4.3节)
• 一个实体主体仅在TRACE请求明确禁止,所有其它请求类型是不受限制的(第9节和9.8特异性)

对于回复,这已经定义:

• 是否包含消息正文取决于请求方法和响应状态(第4.3节)
• 一个消息体在以HEAD请求的响应明确禁止(第9节,和9.4特异性)
• 一个消息体被明确禁止在1XX(信息),204(无内容),和304(未修饰的)反应(第4.3节)
• 所有其他响应都包含一个消息体,尽管它可能是零长度(第4.3节)

这个(RFC 2616)或者这个版本(来自IETF&More In-Depth)就是你想要的.根据RFC:

用于PUT:

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

并为DELETE:

DELETE方法请求源服务器删除Request-URI标识的资源.可以通过源服务器上的人为干预(或其他方式)覆盖此方法.即使从源服务器返回的状态代码表明操作已成功完成,也无法保证客户端已执行该操作.但是,服务器不应该指示成功,除非在给出响应时,它打算删除资源或将其移动到不可访问的位置.

如果响应包括描述状态的实体,则成功响应应为200(OK),如果操作尚未执行,则应为202(已接受);如果操作已颁布但响应不包括,则应为204(无内容)一个实体.

如果请求通过缓存并且Request-URI标识了一个或多个当前缓存的实体,那么这些条目应该被视为陈旧.对此方法的响应不可缓存.

Answer 2

我要回答这个问题：

1. 从请求主体的角度来看，而不是响应主体，因为这是所要求的，也是最令人感兴趣的。
2. 就什么时候需要身体，什么时候禁止身体而言。

请求不需要包含主体，尽管缺少主体可能会被解释为空主体或长度为零的主体。

RFC2616 4.3 规定：

4.3 消息正文 对于请求和响应，消息中何时允许出现消息正文的规则有所不同。

...

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

浏览 5.1.1 中的方法（不包括任何扩展方法）你会发现：

9.8 跟踪

...

TRACE 请求不得包含实体。

因此从技术上讲，任何其他请求方法：

OPTIONS
GET
HEAD
POST
PUT
DELETE
CONNECT

...可以包括身体。回到4.3：

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

因此，在响应特定方法或资源的意外实体主体时，可以安全地忽略它并进行响应（包括响应代码），就好像主体未发送一样。

参考：RFC2616 超文本传输​​协议 -- HTTP/1.1

编辑： RFC2616 确实已经过时了，请参阅RFC7230了解最新规范。