HTTP中GET和POST详细理解

HTTP中GET和POST

简单来说

GET 的语义是从服务器获取指定的资源，这个资源可以是静态的文本、页面、图片视频等。GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）

POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，具体的处理方式资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。

详细来说

1. 定义与用途

   • GET 方法：

     • 定义：GET 方法用于从服务器获取资源。它是幂等的，这意味着对同一资源进行多次相同的 GET 请求，应该返回相同的结果，不会对服务器资源产生额外的影响（除了可能的日志记录等无实质影响的操作）。

     • 用途：通常用于查询操作，如获取网页内容、查询数据列表、获取单个数据项的详细信息等。例如，在浏览器中输入一个网址访问网页，浏览器发送的就是 GET 请求来获取网页的 HTML 文件。再如，通过 API 查询用户信息，GET /api/users/123 可以获取用户 ID 为 123 的用户详细信息。

   • POST 方法：

     • 定义：POST 方法用于向服务器提交数据，通常会导致服务器状态的改变。它不是幂等的，多次相同的 POST 请求可能会在服务器端产生不同的结果，因为每次请求都会提交新的数据并可能改变服务器资源的状态。

     • 用途：广泛用于创建或更新资源。比如，在用户注册功能中，通过 POST 方法将用户填写的注册信息（如用户名、密码、邮箱等）发送到服务器，服务器接收并创建新的用户记录；在更新用户信息时，也可以使用 POST 方法将修改后的用户数据发送给服务器，服务器根据提交的数据更新用户记录。

2. 请求参数传递方式

   • GET 方法：

     • 参数位置：请求参数会附加在 URL 之后，通过 “?” 符号与 URL 路径分隔，多个参数之间用 “&” 符号连接。例如，https://example.com/api/search?keyword=java&page=1，其中 “keyword=java” 和 “page=1” 就是请求参数，这种方式称为查询字符串（Query String）。

     • 数据可见性：由于参数直接暴露在 URL 中，所以数据是可见的，这在某些情况下可能会带来安全风险，如包含敏感信息（如密码）的参数不适合用 GET 方法传递。同时，由于 URL 长度有限制（不同浏览器和服务器对 URL 长度限制不同），所以 GET 方法传递的数据量也受到一定限制。

   • POST 方法：

     • 参数位置：请求参数通常包含在请求体（Request Body）中。请求体的格式可以有多种，如常见的application/x - www - form - urlencoded（类似于 GET 方法的查询字符串格式，但在请求体中）和multipart/form - data（用于上传文件等复杂数据格式）。

     • 数据可见性：数据在请求体中，对于普通用户来说是不可见的，相对 GET 方法更安全一些，并且在数据量上没有像 GET 方法那样严格的 URL 长度限制，理论上可以传递大量的数据，不过实际情况还会受到服务器配置等因素的限制。

3. 缓存特性

   • GET 方法：

     • 缓存适用性：由于 GET 方法主要用于获取资源，所以比较适合缓存。浏览器和一些中间代理服务器可以根据请求的 URL 缓存 GET 请求的响应结果，当再次发起相同的 GET 请求时，如果缓存未过期，就可以直接从缓存中获取响应，而无需再次向服务器发送请求，提高了访问速度和性能。

     • 缓存控制机制：服务器可以通过设置缓存相关的头信息（如Cache - Control、Expires等）来控制 GET 请求响应的缓存时间和缓存条件。例如，Cache - Control: max - age = 3600 表示该资源可以在客户端缓存 1 小时（3600 秒）。

   • POST 方法：

     • 缓存适用性：POST 方法一般不被缓存，因为每次 POST 请求都可能导致服务器资源状态的改变，缓存 POST 请求的响应可能会导致数据不一致等问题。不过，在一些特殊情况下，经过谨慎考虑和特殊配置，也可以对 POST 请求的响应进行缓存，但这种情况比较少见。

     • 缓存控制机制：通常情况下，服务器会设置合适的头信息来指示不要缓存 POST 请求的响应，如Cache - Control: no - cache。

4. 安全性方面

   • GET 方法：

     • 安全风险点：如前面提到的，由于请求参数暴露在 URL 中，存在安全风险。如果包含敏感信息（如密码、认证令牌等），这些信息可能会被记录在浏览器历史记录、服务器日志或者网络传输过程中的中间设备（如代理服务器）上，容易被窃取。此外，由于可以通过 URL 直接构造请求，也容易受到跨站请求伪造（CSRF）攻击。

     • 安全防护措施：对于敏感信息，尽量避免使用 GET 方法传递；在防止 CSRF 攻击方面，可以采用添加随机令牌（Token）等措施，如在 HTML 表单中添加一个隐藏的csrf_token 字段，在服务器端验证该字段的值来确保请求的合法性。

   • POST 方法：

     • 安全风险点：虽然 POST 方法的数据在请求体中相对安全一些，但如果没有采取适当的安全措施，如加密传输（使用 HTTPS），数据在传输过程中仍然可能被窃取。另外，POST 请求也可能会受到一些攻击，如 SQL 注入（如果服务器端对输入数据处理不当，攻击者可以通过在 POST 数据中注入 SQL 语句来破坏数据库）、跨站脚本攻击（XSS，如果没有对 POST 数据进行合适的过滤和验证，可能会导致恶意脚本在客户端执行）等。

     • 安全防护措施：采用 HTTPS 加密传输来保障数据在传输过程中的安全性；在服务器端对 POST 数据进行严格的输入验证、过滤和消毒处理，防止 SQL 注入和 XSS 等攻击。例如，对用户输入的内容进行转义处理，确保输入的内容不会被误解为 SQL 命令或者脚本代码。

GET 和 POST 方法都是安全和幂等的吗？

先说明下安全和幂等的概念：

• 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。

• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

如果从 RFC 规范定义的语义来看：

• GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。所以，可以对 GET 请求的数据做缓存，这个缓存可以做到浏览器本身上（彻底避免浏览器发请求），也可以做到代理上（如nginx），而且在浏览器中 GET 请求可以保存为书签。

• POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。所以，浏览器一般不会缓存 POST 请求，也不能把 POST 请求保存为书签。

小结。

GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。

POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。

但是实际过程中，开发者不一定会按照 RFC 规范定义的语义来实现 GET 和 POST 方法。比如：

• 可以用 GET 方法实现新增或删除数据的请求，这样实现的 GET 方法自然就不是安全和幂等。

• 可以用 POST 方法实现查询数据的请求，这样实现的 POST 方法自然就是安全和幂等。

HTTP 传输的内容都是明文的，虽然在浏览器地址拦看不到 POST 提交的 body 数据，但是只要抓个包就都能看到了

所以，要避免传输过程中数据被窃取，就要使用 HTTPS 协议，这样所有 HTTP 的数据都会被加密传输。

GET 请求可以带 body 吗？

RFC 规范并没有规定 GET 请求不能带 body 的。理论上，任何请求都可以带 body 的。只是因为 RFC 规范定义的 GET 请求是获取资源，所以根据这个语义不需要用到 body。

另外，URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。

参考：

小林coding