哪些HTTP方法需要正文? [英] Which HTTP methods require a body?

问题描述

某些HTTP方法(例如POST)要求在标头和双精度CRLF之后发送正文.

Some HTTP methods, such as POST, require a body to be sent after the headers and the double CRLF.

其他对象(例如GET)没有正文，并且对它们来说，双精度CRLF标记了请求的结束.

Others, such as GET, do not have a body, and for them the double CRLF marks the end of the request.

但是其他人呢:PUT，DELETE，...如何知道哪个人需要尸体?

But what about others: PUT, DELETE, ... how to know which one requires a body?

通用HTTP客户端应如何应对未知的HTTP方法?拒绝吗?默认情况下需要正文，还是默认情况下不需要正文?

How should a generic HTTP client react to an unknown HTTP method? Reject it? Require a body by default, or not require a body by default?

希望您能找到相关规范的指针.

A pointer to the relevant spec would be appreciated.

编辑:如评论中所述，我将详细说明我的问题.

Edit : I'll detail a bit more my question, as asked in the comments.

我正在设计一个通用的HTTP 客户端，程序员可以使用该客户端将任意的HTTP请求发送到任何服务器.

I'm designing a generic HTTP client that a programmer can use to send arbitrary HTTP requests to any server.

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

The client could be used like this (pseudo-code):

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

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

The data is optional, and can be raw data (string), or an associative array of key/value pairs.

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

The library would url-encode the data if it's an array, then either append the data to the URL for a GET request, or send it in the message body for a POST request.

因此，根据开发人员选择的HTTP方法，我试图确定此HttpClient是否必须/应该/必须/不应/不应在请求中包含消息正文.

I'm therefore trying to determine whether this HttpClient must/should/must not/should not include a message-body in the request, given the HTTP method chosen by the developer.

推荐答案

编译列表:

• 实体 仅在存在消息体时出现(第7.2节)
• 邮件正文的存在是通过包含Content-Length或Transfer-Encoding标头(第4.3节)来表示的.
如果请求方法的规范不允许发送实体(第4.3节)，则不得包含
• 消息正文"
• 实体仅在TRACE请求中被明确禁止，所有其他请求类型均不受限制(特别是第9和9.8节)

• an entity-body is only present when a message-body is present (section 7.2)
• the presence of a message-body is signaled by the inclusion of a Content-Length or Transfer-Encoding header (section 4.3)
• a message-body must not be included when the specification of the request method does not allow sending an entity-body (section 4.3)
• an entity-body is explicitly forbidden in TRACE requests only, all other request types are unrestricted (section 9, and 9.8 specifically)

对于响应，已定义为:

• 是否包含 message-body 取决于请求方法和响应状态(第4.3节)
• 消息正文在响应HEAD请求时被明确禁止(特别是第9节和第9.4节)
• 消息正文在1xx(信息性)，204(无内容)和304(未修改)响应中被明确禁止(第4.3节)
• 所有其他响应都包括一个消息正文，尽管它的长度可能为零(第4.3节)

• whether a message-body is included depends on both request method and response status (section 4.3)
• a message-body is explicitly forbidden in responses to HEAD requests (section 9, and 9.4 specifically)
• a message-body is explicitly forbidden in 1xx (informational), 204 (no content), and 304 (not modified) responses (section 4.3)
• all other responses include a message-body, though it may be of zero length (section 4.3)

此 (RFC 7231)或 此 版本(来自IETF&您想要的是更多深度".根据RFC:

This (RFC 7231) Or This version (From IETF & More In-Depth) is what you want. According to the RFC:

对于PUT:

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

The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.

对于DELETE:

DELETE方法请求原始服务器删除资源 由Request-URI标识.该方法可能被人类覆盖 原始服务器上的干预(或其他方式).客户不能 确保即使已执行了操作 从原始服务器返回的状态代码表示该操作 已成功完成.但是，服务器不应该 表示成功，除非在做出回应时有意 删除资源或将其移动到无法访问的位置.

The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.

如果响应中包含一个成功的响应，则应为200(确定) 描述状态的实体，如果操作尚未完成，则为202(接受) 已执行；如果已执行，则返回204(无内容)，但 该响应不包含实体.

A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity.

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

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

这篇关于哪些HTTP方法需要正文?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！