如何在HTTP POST请求中发送参数？
在HTTP GET请求中，参数作为查询字符串发送：
http://example.com/page?parameter=value&also=another
在HTTP POST请求中，参数不会与URI一起发送。
价值在哪里？ 在请求头中？ 在请求正文中？ 它是什么样子的？
这些值以内容类型指定的格式在请求正文中发送。
通常内容类型是application/x-www-form-urlencoded ，所以请求主体使用与查询字符串相同的格式：
parameter=value&also=another
当您在表单中使用文件上载时，可以使用multipart/form-data编码，而不是格式。 它比较复杂，但你通常不需要关心它的外观，所以我不会展示一个例子，但它可以很好地知道它存在。
内容放在HTTP头之后。 HTTP POST的格式是具有HTTP标头，后跟空行，后跟请求主体。 POST变量作为键值对存储在主体中。
您可以在HTTP Post的原始内容中看到此内容，如下所示：
POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=flies
你可以使用像Fiddler这样的工具来查看这个工具，你可以使用它来观察通过线路发送的原始HTTP请求和响应有效载荷。
简短回答：在POST请求中，值是在请求的“正文”中发送的。 通过网络表单，他们很可能会与媒体类型的application/x-www-form-urlencoded或multipart/form-data 。 被设计为处理网络请求的编程语言或框架通常会提供这样的请求的“正确的事情™”，并为您提供易于解码的值（例如PHP中的$_REQUEST或$_POST ，或者cgi.FieldStorage() ，Python中的flask.request.form ）。
现在我们稍微离题一下，这可能有助于理解差异;）
GET和POST请求之间的区别在很大程度上是语义上的。 它们的“使用方式”也有所不同，这就解释了值如何传递的差异。
GET（相关RFC部分）
执行GET请求时，您可以向服务器请求一个或一组实体。 为了允许客户端过滤结果，它可以使用URL的所谓“查询字符串”。 查询字符串是? 。 这是URI语法的一部分。
因此，从您的应用程序代码（接收请求的部分）的角度来看，您需要检查URI查询部分以获取对这些值的访问权限。
请注意，键和值是URI的一部分。 浏览器可能会对URI长度施加限制。 HTTP标准规定没有限制。 但在撰写本文时，大多数浏览器确实限制了URI（我没有具体的值）。 绝不应该使用GET请求来向服务器提交新信息。 特别是不大的文件。 这就是你应该使用POST或者PUT 。
POST（相关RFC部分）
执行POST请求时，客户端实际上是向远程主机提交新文档。 所以，查询字符串不（语义上）是有意义的。 这就是为什么你没有在应用程序代码中访问它们的原因。
POST稍微复杂一点（而且更灵活）：
当收到一个POST请求时，你应该总是期待一个“有效载荷”，或者用HTTP的方式来看：一个消息体。 消息体本身是无用的，因为没有标准（据我所知，也许是application / octet-stream？）格式。 正文格式由Content-Type标题定义。 当使用method="POST"的HTML FORM元素时，通常是application/x-www-form-urlencoded 。 如果您使用文件上传，另一种非常常见的类型是multipart / form-data。 但可以是任何东西，从text/plain ， application/json甚至自定义application/octet-stream 。
在任何情况下，如果使用无法由应用程序处理的Content-Type发出POST请求，它应该返回一个415状态码。
大多数编程语言（和/或Web框架）提供了一种将消息体从/最常见类型（如application/x-www-form-urlencoded ， multipart/form-data或application/json ）中multipart/form-data application/x-www-form-urlencoded 。 。 这很简单。 自定义类型需要更多的工作。
以标准HTML表单编码文档为例，应用程序应执行以下步骤：
Content-Type字段 415状态码的响应 再次，像PHP这样的语言或其他流行语言的Web框架可能会为您处理。 这个例外是415错误。 没有框架可以预测您的应用程序选择支持和/或不支持哪些内容类型。 这取决于你。
PUT（相关RFC部分）
PUT请求的处理方式与POST请求完全相同。 最大的区别是POST请求应该让服务器决定如何（并且如果有的话）创建一个新的资源。 历史上（从现在过时的RFC2616开始，它创建一个新的资源作为发送请求的URI的“下级”（子））。
相比之下， PUT请求应该准确地在该URI处“准确”存储资源，并准确地存储该内容。 没有更多，不少。 这个想法是，客户有责任在“推销”之前制作完整的资源。 服务器应该在给定的URL上按原样接受它。
因此， POST请求通常不用于替换现有资源。 PUT请求既可以创建也可以替换。
边注
还有一些“路径参数”可用于向远程设备发送附加数据，但它们非常罕见，我不会在这里详细讨论。 但是，作为参考，这里是RFC的摘录：
除了分层路径中的点段，通用语法将路径段视为不透明。 生成URI的应用程序通常使用段中允许的保留字符来分隔方案特定的或解引用处理程序特定的子组件。 例如，分号（“;”）和等号（“=”）保留字符通常用于分隔适用于该分段的参数和参数值。 逗号（“，”）保留字符通常用于类似的目的。 例如，一个URI生产者可以使用诸如“name; v = 1.1”的段来表示对“name”的版本1.1的引用，而另一个可以使用诸如“name，1.1”的段来表示相同的段。 参数类型可以通过特定于方案的语义来定义，但是在大多数情况下，参数的语法特定于实现URI解引用算法。
链接地址: http://www.djcxy.com/p/1085.html