在 HTTP GET 请求中，参数作为 查询字符串 发送：
http://example.com/page?parameter=value&also=another
在 HTTP POST 请求中，参数不与 URI 一起发送。
值在哪里？在请求标头中？在请求正文中？它看起来像什么？
【问题讨论】：
标签： http post parameters request uri
HTTP POST 中的表单值在请求正文中发送，格式与查询字符串相同。
有关详细信息，请参阅spec。
【讨论】：
? 开头？
application/x-www-form-urlencoded时，并非总是如此。
内容放在 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 请求和响应负载。
【讨论】：
application/x-www-form-urlencoded时，并非总是如此。
From 标题？
From 标头。 IMO 它带有 418 HTTP 状态代码。
您不能直接在浏览器的 URL 栏上键入它。
例如，您可以使用Live HTTP Headers 来查看 POST 数据是如何在 Internet 上发送的。 结果会是这样的
http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password
上面写着
Content-Length: 30
username=zurfyx&pass=password
将是帖子值。
【讨论】：
Content-Length 应该是29 吗？这是字符串username=zurfyx&pass=password的实际长度。
值以内容类型指定的格式在请求正文中发送。
通常内容类型为application/x-www-form-urlencoded，所以请求正文使用与查询字符串相同的格式：
parameter=value&also=another
当您在表单中使用文件上传时，您使用的是multipart/form-data 编码，它具有不同的格式。它更复杂，但您通常不需要关心它的外观，所以我不会展示示例，但知道它存在会很好。
【讨论】：
multipart/form-data的信息会更好。不过，对于那些感兴趣的人，这里是a question about it。
multipart/form-data 编码的格式上传 json 文件，或者如果您负责请求构造，请将 content-type 更改为 application/json 并将 json 文本直接粘贴到 http 正文中
POST 请求中的默认媒体类型是application/x-www-form-urlencoded。这是一种编码键值对的格式。密钥可以重复。每个键值对由& 字符分隔，每个键与其值由= 字符分隔。
例如：
Name: John Smith
Grade: 19
编码为：
Name=John+Smith&Grade=19
这被放置在 HTTP 标头之后的请求正文中。
【讨论】：
简短回答： 在 POST 请求中，值在请求的“正文”中发送。对于网络表单，它们最有可能使用application/x-www-form-urlencoded 或multipart/form-data 的媒体类型发送。设计用于处理网络请求的编程语言或框架通常对此类请求执行“正确的事情™”，并为您提供对易于解码的值的轻松访问（如 PHP 中的 $_REQUEST 或 $_POST 或 @987654334 @, flask.request.form 在 Python 中）。
现在让我们离题一点，这可能有助于理解其中的区别；）
GET 和 POST 请求之间的区别主要是语义上的。它们的“使用”方式也不同，这解释了值传递方式的差异。
在执行GET 请求时，您向服务器请求一个或一组实体。为了允许客户端过滤结果，它可以使用 URL 的所谓“查询字符串”。查询字符串是? 之后的部分。这是URI syntax 的一部分。
因此，从您的应用程序代码（接收请求的部分）的角度来看，您将需要检查 URI 查询部分以访问这些值。
请注意，键和值是 URI 的一部分。浏览器可能对 URI 长度施加限制。 HTTP 标准声明没有限制。但在撰写本文时，大多数浏览器确实限制了 URI（我没有具体的值）。 GET 请求应该永远用于向服务器提交新信息。特别是不是更大的文件。这就是你应该使用POST 或PUT 的地方。
当执行POST 请求时，客户端实际上是在向远程主机提交一个新的文档。因此，query 字符串（在语义上）没有意义。这就是您无法在应用程序代码中访问它们的原因。
POST 稍微复杂一点（方式更灵活）：
当接收到一个 POST 请求时，您应该总是期待一个“有效负载”，或者，用 HTTP 术语来说：message body。消息体本身没什么用，因为没有标准（据我所知。也许是application/octet-stream？）格式。正文格式由Content-Type 标头定义。当使用带有method="POST" 的HTML FORM 元素时，这通常是application/x-www-form-urlencoded。如果您使用文件上传，另一种非常常见的类型是multipart/form-data。但它可能是任何东西，范围从text/plain、application/json 甚至是自定义的application/octet-stream。
在任何情况下，如果 POST 请求是由应用程序无法处理的 Content-Type 发出的，它应该返回一个 415 status-code。
大多数编程语言（和/或网络框架）都提供了一种将消息正文从最常见类型（如application/x-www-form-urlencoded、multipart/form-data 或application/json）解码/编码的方法。所以这很容易。自定义类型可能需要更多的工作。
以标准的 HTML 表单编码文档为例，应用程序应执行以下步骤：
Content-Type 字段415 状态代码的响应同样，PHP 等语言或其他流行语言的网络框架可能会为您处理这个问题。对此的例外是415 错误。没有框架可以预测您的应用程序选择支持和/或不支持哪些内容类型。这取决于你。
PUT 请求的处理方式与POST 请求的处理方式几乎相同。最大的区别在于POST 请求应该让服务器决定如何（如果有的话）创建新资源。从历史上看（从现在已经过时的 RFC2616 开始，它是创建一个新资源作为请求发送到的 URI 的“从属”（子）。
相比之下，PUT 请求应该将资源准确地“存放”在该 URI 处，并且准确地 使用该内容。不多也不少。这个想法是 client 负责在“PUT”之前制作 complete 资源。服务器应该在给定的 URL 上按原样接受它。
因此，POST 请求通常不用于替换现有资源。 PUT 请求可以同时创建和替换。
还有“path parameters”可以用来向远程发送额外的数据，但它们太少见了，我在这里不再赘述。但是，作为参考，这里是 RFC 的摘录：
除了层次路径中的点段之外，还考虑了路径段 通过通用语法不透明。生成 URI 的应用程序经常使用 段中允许的保留字符来分隔特定于方案的或 取消引用处理程序特定的子组件。例如，分号 (";") 和等号 ("=") 保留字符通常用于分隔参数和 适用于该段的参数值。逗号 (",") 保留 字符通常用于类似目的。例如，一个 URI 生产者 可以使用诸如“name;v=1.1”之类的段来指示对版本的引用 "name" 的 1.1，而另一个可能使用诸如 "name,1.1" 之类的段来 表示相同。参数类型可以由特定于方案的定义 语义，但在大多数情况下，参数的语法是特定的 到 URI 解引用算法的实现。
【讨论】：
PUT 部分的第二段，您会发现它是 幂等的。 POST 相反可以 - 根据定义 - 不是。 POST 将始终创建一个新资源。如果存在相同的资源，PUT 将替换它。所以如果你调用POST 10 次，你将创建 10 个资源。如果你调用PUT 10 次，它（可能）只会创建一个。这能回答你的问题吗？
一些网络服务要求您分别放置请求数据和元数据。例如，远程函数可能期望已签名的元数据字符串包含在 URI 中，而数据则发布在 HTTP 正文中。
POST 请求在语义上可能如下所示：
POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)
name id
John G12N
Sarah J87M
Bob N33Y
这种方法在逻辑上使用单个 Content-Type 将 QueryString 和 Body-Post 组合在一起，这是 Web 服务器的“解析指令”。
请注意：HTTP/1.1 被包装，左侧是#32（空格），右侧是#10（换行符）。
【讨论】：
/user/john 和/?user=john 之间的区别只是语义上的区别（HTTP 并没有真正对查询字符串进行特殊处理），所以我认为这是合理的预期。但是“被左边的空格包裹”是什么意思？ HTTP 方法之前没有空格。你的意思是帖子正文的空行？
...Ym04 和HTTP/1.1 之间有一个空格（ASCII #32）。所以 QueryString 只是位于动词和协议版本之间。
? 分隔URI 和参数来将查询参数作为URL 的一部分传递，就像我们对GET 请求所做的那样。
首先，让我们区分GET和POST
获取： 这是向服务器发出的默认HTTP 请求，用于从服务器检索数据以及URI 中? 之后的查询字符串用于检索唯一资源。
这是格式
GET /someweb.asp?data=value HTTP/1.0
这里data=value是传递的查询字符串值。
POST：它用于安全地向服务器发送数据，所以需要任何东西，这是POST请求的格式
POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename
为什么 POST 优于 GET？
在GET 中，发送到服务器的值通常附加到查询字符串中的基本 URL，现在有两个后果
GET 请求与参数一起保存在浏览器历史记录中。因此，您的密码在浏览器历史记录中保持未加密状态。在过去，这对 Facebook 来说是一个真正的问题。URI 的长度有限制。如果发送的参数过多，您可能会收到414 Error - URI too long 在发布请求的情况下，您来自字段的数据将被添加到正文中。计算请求参数的长度，并添加到内容长度的头部，没有重要数据直接附加到URL。
您可以使用 Google 开发者工具的网络部分查看有关如何向服务器发出请求的基本信息。
您可以随时在 Request Headers 中添加更多值，例如 Cache-Control、Origin、Accept。
【讨论】：
HTTPS 连接的上下文中成立，而不是HTTP。 HTTPS 加密URL（包括查询参数）和Request Body，而HTTP 既不加密/保护也不加密。所描述的问题来自许多浏览器将URIs（包括URLs）存储在其历史数据库中（通常未加密）的事实。因此，对于任何敏感内容，请仅使用 Request Body+HTTPS。
post参数有多种方式/格式
它们由表示为 mime 类型的 Header 中的内容类型控制。
【讨论】：