HTTP 请求方法的有效负载
HTTP 上的维基百科条目列出了以下 HTTP 请求方法：
- HEAD： 要求相同的响应对应于 GET 请求，但没有响应正文。
- GET：请求指定资源的表示。
- POST：将要处理的数据（例如，来自 HTML 表单）提交到所识别的资源。数据包含在请求正文中。
- PUT：上传指定资源的表示。
- DELETE：删除指定的资源。
- TRACE：回显收到的请求，以便客户端可以看到中间服务器进行了哪些（如果有）更改或添加。
- 选项：返回服务器支持指定 URL 的 HTTP 方法。这可用于通过请求“*”而不是特定资源来检查 Web 服务器的功能。
- CONNECT：将请求连接转换为透明 TCP/IP 隧道，通常是为了通过未加密的 HTTP 代理进行 SSL 加密通信 (HTTPS)。
- PATCH： 用于对资源应用部分修改。
我有兴趣了解（特别是关于前五个方法）：
- 这些方法中哪些能够（应该？）接收有效负载
- 可以接收有效负载的方法，它们是如何接收的？
- 通过网址中的查询字符串？
- 通过 URL 编码的正文？
- 通过原始/分块正文？
- 通过上述（[全部/部分]）的组合？
- 可以接收有效负载的方法，它们是如何接收的？
我感谢所有的意见，如果你能分享一些（最好是轻松的）阅读，那就太好了！
The Wikipedia entry on HTTP lists the following HTTP request methods:
- HEAD: Asks for the response identical to the one that would correspond to a GET request, but without the response body.
- GET: Requests a representation of the specified resource.
- POST: Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request.
- PUT: Uploads a representation of the specified resource.
- DELETE: Deletes the specified resource.
- TRACE: Echoes back the received request, so that a client can see what (if any) changes or additions have been made by intermediate servers.
- OPTIONS: Returns the HTTP methods that the server supports for specified URL. This can be used to check the functionality of a web server by requesting '*' instead of a specific resource.
- CONNECT: Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.
- PATCH: Is used to apply partial modifications to a resource.
I'm interested in knowing (specifically regarding the first five methods):
- which of these methods are able (supposed to?) receive payloads
- of the methods that can receive payloads, how do they receive it?
- via query string in URL?
- via URL-encoded body?
- via raw / chunked body?
- via a combination of ([all / some] of) the above?
- of the methods that can receive payloads, how do they receive it?
I appreciate all input, if you could share some (preferably light) reading that would be great too!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
以下是 RFC 7231 的摘要，它是链接@Darrel发布：
@John 还提到，所有请求方法都支持 URL 中的查询字符串（一个值得注意的例外可能是 OPTIONS，它似乎仅在 URL 为
HOST/*< 时才有用 [在我的测试中] /代码>）。我还没有测试CONNECT和PATCH方法，因为我对它们ATM不感兴趣。
Here is the summary from RFC 7231, an updated version of the link @Darrel posted:
As @John also mentioned, all request methods support query strings in the URL (one notable exception might be OPTIONS which only seems to be useful [in my tests] if the URL is
HOST/*).I haven't tested the CONNECT and PATCH methods since I have no interest in them ATM.
RFC 7231，HTTP 1.1 语义和内容，是最新的、 HTTP 方法语义的权威来源。该规范规定，对于 GET、HEAD、OPTIONS 或 CONNECT 消息中可能包含的有效负载，没有定义含义。第 4.3.8 节规定客户端不得发送 TRACE 请求的正文。因此，只有 TRACE 不能有有效负载，但 GET、HEAD、OPTIONS 和 CONNECT 可能不会，并且如果客户端发送有效负载，服务器不希望知道如何处理它（意味着它可以忽略它）。
如果您认为任何内容不明确，那么可以使用邮件列表您可以在这里表达您的担忧。
RFC 7231, HTTP 1.1 Semantics and Content, is the most up-to-date and authoritative source on the semantics of the HTTP methods. This spec says that there are no defined meaning for a payload that may be included in a GET, HEAD, OPTIONS, or CONNECT message. Section 4.3.8 says that the client must not send a body for a TRACE request. So, only TRACE cannot have a payload, but GET, HEAD, OPTIONS, and CONNECT probably won't and the server isn't expected to know how to handle it if the client sends one (meaning it can ignore it).
If you believe anything is ambiguous, then there is a mailing list where you can voice your concerns.
我很确定 GET 请求是否可以有有效负载尚不清楚。 GET 请求通常通过查询字符串发布表单数据，HEAD 请求也是如此。 HEAD 本质上是 GET - 只是它不需要响应主体。
（旁注：我说这并不清楚，因为 GET 请求在技术上可以升级到另一个协议；事实上，Websockets 的一个版本就是这样做的，虽然一些代理软件可以很好地使用它，但其他软件在握手时会被阻塞。
）有一个身体。没有什么可以阻止您使用查询字符串，但 POST 正文通常会在 POST 中包含表单数据。
有关更多（更详细）的信息，我会点击实际的 HTTP/1.1 规范。
I'm pretty sure it's not clear whether or not GET requests can have payloads. GET requests generally post form data through the query string, same for HEAD requests. HEAD is essentially GET - except it doesn't want a response body.
(Side note: I say it's not clear because a GET request could technically upgrade to another protocol; in fact, a version of websockets did just this, and while some proxy software worked fine with it, others chocked upon the handshake.)
POST generally has a body. Nothing is stopping you from using a query string, but the POST body will generally contain form data in a POST.
For more (and more detailed) information, I'd hit the actual HTTP/1.1 specs.