HTTP请求方法的有效负载

列出了以下HTTP请求方法：

• 头：请求与GET请求对应的响应相同的响应，但没有响应主体
• GET:请求指定资源的表示形式
• POST:将要处理的数据（例如，从HTML表单）提交到标识的资源。数据包含在请求正文中
• PUT:上载指定资源的表示形式
• 删除：删除指定的资源
• 跟踪：回显收到的请求，以便客户端可以看到中间服务器所做的更改或添加（如果有）
• 选项：返回服务器对指定URL支持的HTTP方法。这可以通过请求“*”而不是特定资源来检查web服务器的功能
• 连接：将请求连接转换为透明的TCP/IP隧道，通常用于通过未加密的HTTP代理促进SSL加密通信（HTTPS）
• 补丁：用于对资源应用部分修改

我有兴趣知道（特别是关于前五种方法）：

• 这些方法中哪些能够（应该？）接收有效载荷
  • 在可以接收有效载荷的方法中，它们是如何接收的？
    • 通过URL中的查询字符串
    • 通过URL编码的身体
    • 通过生的/大块的身体
    • 通过上述（全部/部分）的组合

---

我很感激所有的输入，如果你能分享一些（最好是轻）阅读，那也太好了

我很确定GET请求是否可以有有效负载还不清楚。GET请求通常通过查询字符串发布表单数据，HEAD请求也是如此。HEAD本质上是GET，只是它不需要一个响应体

（旁注：我说不清楚，因为GET请求在技术上可以升级到另一个协议；事实上，websockets的一个版本正好做到了这一点，虽然一些代理软件可以很好地使用它，但其他一些代理软件却在握手时被卡住了。）

邮政一般有一个机构。没有什么可以阻止您使用查询字符串，但POST正文通常会在POST中包含表单数据

要获得更多（和更详细）的信息，我会点击实际的。HTTP 1.1语义和内容是关于HTTP方法语义的最新和权威的来源。该规范指出，GET、HEAD、OPTIONS或CONNECT消息中可能包含的有效负载没有定义的含义。第4.3.8节规定，客户不得发送跟踪请求的主体。因此，只有TRACE不能有有效负载，但是GET、HEAD、OPTIONS和CONNECT可能不会，并且如果客户端发送有效负载，服务器不需要知道如何处理它（这意味着它可以忽略它）

如果你认为任何事情都是模棱两可的，那么你就可以表达你的担忧了。

以下是一个更新版本的链接摘要：

• 头部-未定义身体语义
• 获取-未定义正文语义
• 将身体支撑起来
• POST车身支撑
• 删除-未定义正文语义
• 跟踪-不支持正文
• 选项支持正文，但在用法上没有语义（可能在将来）
• 连接-未定义正文语义

如前所述，所有请求方法都支持URL中的查询字符串（一个值得注意的例外可能是选项，只有在URL为

HOST/*

的情况下，[在我的测试中]这似乎才有用）

---

我没有测试过CONNECT和PATCH方法，因为我对它们不感兴趣。

当我说payload时，我也将在URL中执行的数据作为查询字符串引用。我知道

POST

希望通过URL编码的正文和/或URL查询字符串获得有效负载

GET

支持通过URL查询字符串加载有效负载，我认为

HEAD

和

DELETE

也会出现同样的情况，但我不能100%确定这一点。我阅读了HTTP/1.1 RFC的第9节，但我似乎不太清楚，

DELETE

请求是否可以有一个正文，也不完全清楚。但是，HTTP/1.1 RFC中没有任何内容禁止它。而且，查询字符串可以出现在任何请求中，而不仅仅是

GET

，

HEAD

和

DELETE

-表单数据在

POST

中发布到body，而在

GET

中发布到查询字符串，这一事实可能比任何内容都更与HTML相关。Httpbis非常清楚地说明了在DELETE中发送body意味着什么，这并不意味着什么，一些现有的internet组件可能会拒绝它。GET也是一样。@Darrel Miller:哦，好吧，我不知道。Httpbis规范的目标是澄清RFC2616忘记说或没有说好的内容。我仍然需要更详细地阅读它，但似乎Httpbis草案进入了我希望知道的那种细节。谢谢我不确定“最权威”是什么，因为它们仍然是可能更改的草稿。尽管如此，我同意它们对于澄清RFC2616中的歧义是有用的。OPTIONS采用与任何其他方法相同的URI集，然后应用于该资源。它仅适用于“*”。Connect是否有有效负载？@cmcdragokai：“Connect请求上的主体没有定义的语义。请注意，在Connect请求上发送主体可能会导致某些现有实现拒绝该请求”。@AlixAxel您可以将添加到列表中吗？它不够详尽，无法成为公认的answ