侧边栏壁纸
  • 累计撰写 247 篇文章
  • 累计创建 16 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

HTTP 请求方法

kaixindeken
2021-04-23 / 0 评论 / 0 点赞 / 107 阅读 / 2,623 字

在请求报文的第一行第一个元素就是 HTTP 方法,HTTP 协议主要支持的方法包括以下这些:

1.jpeg

在整篇教程中,我们将基于 TELNET 工具模拟 HTTP 通信或者通过抓包工具分析请求报文和响应报文。

截屏20210423 上午9.19.38.png

这是我们日常最常见的 HTTP 方法了,由于 GET 请求不会对服务器资源产生副作用(只是获取资源,不会对资源进行变更,但是这一点需要开发者保证,通过 GET 请求变更服务器资源有重大安全隐患,在开发过程中国要避免这么做),所以我们通常将其称为安全的 HTTP 方法,而与之相对的,将 PUT、POST、DELETE、PATCH 这些会对服务器资源造成变更的方法称作不安全的 HTTP 方法。

HEAD 方法和 GET 方法类似,但只返回 HTTP 首部,不返回报文主体部分,通常用于确认 URL 的有效性及资源更新的日期时间等:

截屏20210423 上午9.23.17.png

显然,和 GET 方法一样,HEAD 方法也是安全的 HTTP 方法。

POST

POST 方法用来向服务器发送数据,通常用它来支持 HTML 的表单,POST 请求会对服务器资源进行变更(这一点需要开发者保证,HTTP 协议本身没有强制要求这么做,你完全可以通过 GET 请求发送数据,但是从安全角度说,强烈建议这么做,即用 POST 方法发送变更资源的请求),是不安全的 HTTP 方法。

请求实体部分就是待提交的表单数据,请求到达 Web 服务器后,通过 PHP 程序处理,服务器将响应返回给客户端。

PUT

PUT 方法设计的初衷是用来传输文件,就像 FTP 协议的文件上传一样,要求在报文的主体中包含文件内容,然后保存到请求 URI 指定的位置。但是,由于 PUT 方法自身不带验证机制,任何人都可以上传文件,存在安全性问题,因此一般 Web 网站不会通过该方法来上传文件。若配合 Web 应用程序的验证机制,则可能会开放使用 PUT 方法。

PUT 方法的语义就是让服务器用请求主体部分来创建一个由所请求的 URL 命令的新文档,或者,如果那个 URL 已经存在的话,就用这个主体来替代它,因此,我们会看到在 RESTful 架构中,我们一般使用 PUT 方法来更新资源,Laravel 框架中的资源控制器就是这么做的。

与 PUT 方法类似的还有一个 PATCH 方法,用于对指定资源进行部分修改(PUT 方法用于整体覆盖),但是日常开发中,我们不会分的这么细,通常,可以用 PATCH 的地方,往往就可以用 PUT 方法替代。

和 POST 方法一样,PUT 方法也是不安全的 HTTP 方法。具体请求和响应报文格式和 POST 类似,这里不再重复演示了。

需要注意的是,在 Nginx 中,默认只支持对静态资源进行 GET、POST、HEAD 请求,其他 HTTP 方法都会返回 405 Method Not Allowed,要支持的其他 HTTP 方法的话需要配置。

DELETE

DELETE 方法设计的初衷是用来删除文件,是与 PUT 请求相对的方法,DELETE 方法按请求 URI 删除指定的资源。但是,HTTP/1.1 的 DELETE 方法和 PUT 方法一样不带验证机制,所以一般 Web 网站也不使用 DELETE 方法进行文件删除,当配合 Web 应用程序的验证机制,或遵守 REST 标准时还是有可能会开放使用的。

目前我们会在 RESTful 架构中,通过 DELETE 方法来删除资源(不一定是文件),Laravel 框架中的资源控制器就是这么做的。DELETE 请求报文中不需要报文实体,只需要通过 URL 来定位资源即可。和 PUT 方法一样,我们需要在 HTML 表单中伪造 DELETE 方法才能让 Nginx 支持 DELETE 请求。

和 POST 方法一样,DELETE 方法也是不安全的 HTTP 方法。

OPTIONS

OPTIONS 方法用来查询针对请求 URL 指定的资源支持的所有 HTTP 方法。Nginx 默认也不支持对资源发起 OPTIONS 请求。

TRACE

客户端发起一个请求时,这个请求可能要穿过防火墙、代理、网关或其他一些应用程序,每个中间节点都可能会修改原始的 HTTP 请求,TRACE 方法允许客户端在最终请求发送给服务器时,看看它变成了什么样子。该命令主要用于 HTTP 通信的诊断和调试。

TRACE 请求会在目标服务器端发起一个「环回」诊断,行程最后一站的服务器会返回一条 TRACE 响应,并在响应主体中携带它收到的原始请求报文,这样,客户端就可以查看在所有中间 HTTP 应用程序组成的请求/响应链上,原始报文是否以及如何被修改过。

发送 TRACE 请求时,可以在 Max-Forwards 首部字段中填入数值,每经过一个服务器/中间节点该数值就会减1,当数值刚好减到0时,就停止继续传输,最后接收到请求的服务器/节点则返回状态码 200 OK 的响应(不管是否到达最终目标服务器都会返回,不会再继续传递请求)。

但是,TRACE 方法并不怎么常用,再加上容易引发 XST(Cross-Site Tracing,跨站追踪)攻击,就更不会用到了。

0

评论区