chrome devtool -- http general

雾中航行志趣
670 阅读9分钟

前言

打开调试工具，进入 GitHub 首页后，在 “network” 选项卡下有一些请求，接下来的几篇文章我将深入探究请求报文中的字段都是起什么作用的，如何起作用的，首先本篇探究 general 部分的字段。

heneral1.png

这个部分的字段是揭示了请求的核心的，一般包含五个部分：

  • Request URL
  • Request Method
  • Status Code
  • Remote Address
  • Referrer Policy

但是，也会有特殊情况，

比如有时候 Remote Address 就不会出现（情况 1）

heneral1.png 有时候这部分只有 Request URL 和 Referrer Policy 两个字段（情况 2）

general3.png 要了解为什么，首先我们要搞清楚这五个字段都分别起到什么作用，以及是如何起作用的。

Request URL

顾名思义，这个字段标识了这个请求的目标地址，说明请求要走过长长的网线到达这个地址之后才会开始返回，ok，这个字段真的很简单。主要是要理解这个字段的值的含义：Uniform Resource Locator 统一资源定位符，标识计算机网络中唯一的一份资源；

标准格式：

  • 协议类型

    其实有非常之多，比如 curl 就支持 34 种协议（但是今天我只想好好了解http[s]）

curl is a tool for transferring data from or to a server. It supports these protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET or TFTP. The command is designed to work without user interaction.

  • 服务器地址

    一般是 IP 地址或者 IP 地址解析的域名

  • 端口号

    和协议有关，http 常用 80，https 常用 443，浏览器默认会根据协议来省略显示

  • 文件路径

    支持 unix 格式的文件目录，也就是说要用 "/" 而不是用 ""

  • ?查询

    和请求方法有关，接下来说明

  • #片段ID

    HTML 文件中的 id 值，浏览器发起这样的请求时，会将 id 值对应的片段显示的显示器画面的顶部（其他环境我没试过）

Request Method

ok，现在我们找到地址了，接下来我们看看我们要对这个地址的资源干些啥好呢？这就是 request method 这个字段的作用啦。

常用的方法有 GET,POST,HEAD,PUT,DELETE,OPTION,CONNECT. 那它们分别是干什么呢？我们先假设一个游客甲出门旅游，

  • 甲到达景点之后，他有可能只是一饱眼福把景色看光，存起来，这和GET 一个作用，GET 也是从资源地址获取资源。

  • 可能甲到景点里，在某地写了“甲到此一游”这一行字，对景点造成了修改，就和 POST 一个作用了，POST 会对资源地址里的资源进行修改。

  • 甲想要知道景点多大，自己一天能不能逛完，所以他先对景点整体范围进行考察，这和 HEAD 一个作用，HEAD 的一个场景就是，下载大文件时，先看看文件大小决定。

  • 甲想在景区里吃饭，于是就带着饭进入了景区，后来甲在景区产生了生活垃圾。这和 PUT 一样，PUT 也会对资源地址进行内容形式的更新。

  • 甲想从景区里顺走一颗鹅卵石，于是他带着荷包去了景区，把想要偷的鹅卵石从景区带走了。这和 DELETTE 一样，DELETE 会对资源地址进行指向性删除操作，将资源从地址中删掉。

  • 甲不知道自己上面这些行为会不会得到允许，所以他先给景区的工作人员打个电话问了问。这和 OPTION 方法一样，OPTION 方法会获得资源地址支持哪些访问方法。

  • 景区门票太难抢了，甲想买黄牛票，也就是甲-黄牛-景区，这和 CONNECT 方法一样，CONNECT 方法会发生在代理服务器上，会对资源地址和请求地址建立一个 TCP 连接，让他们能够联通。

    理解HTTP CONNECT通道

更加深入的请求方法内容以后再来探索吧，我们接着 status code 看。

Status Code

HTTP 状态码是服务器对浏览器端请求的三位数响应。比如经典的 404 page not found 。状态码用作服务器和 Internet 浏览器之间的一种通信方式，并且根据它们正在通信的信息类型有多个代码类。类的区别通过错误码的第一个数字来表示：

  • 1XX：

    1xx 信息状态代码表示服务器已收到请求并正在继续该过程。1xx 状态码纯粹是临时的，在请求处理继续时给出。对于大多数任务，通常不会遇到，因为它不是对请求的最终响应。

  • 2XX

    2xx 成功状态码意味着请求成功并且浏览器已经收到预期的信息。这通常是希望看到的，因为这意味着请求是成功的并且已被接收、理解和接受。

    200 OK状态码表示请求成功，但成功的含义取决于使用的请求方法：

    • GET：请求的资源已被获取并传输到消息体。
    • HEAD：来自所请求资源的标头字段在没有消息正文的情况下发送。
    • POST 或 PUT：将操作结果的描述传输到消息体。
    • TRACE：服务器收到的请求消息将包含在消息正文中

    从 SEO 角度来看，200 OK 响应代码是功能页面的完美状态代码，所有链接页面都在正常工作。200 表示搜索引擎爬虫可以成功爬取该页面并将其放入其搜索索引中。

  • 3XX

    3xx 重定向状态代码表示请求已被重定向并且请求的完成需要进一步的操作。重定向是互联网的自然组成部分，不要害怕有 3xx 重定向状态代码。重定向意味着请求已成功接收，但资源在其他地方找到。如果网页已更改路径但是依然尝试通过旧路径访问它，网站的 CMS 通常会将用户重定向到新路径。最终请求将以 2xx 成功结束，但首先它必须经过 3xx 重定向。

  • 4XX

    4xx 客户端错误状态代码表示无法访问网站或页面，并且页面不可用或请求包含错误的语法。会降低 SEO 。这是一个客户端错误。

  • 5XX

    5xx 服务器错误状态代码意味着虽然请求看起来有效，但服务器无法完成请求。这是一个服务端错误。

总的来说，状态码就是直观体现了当前请求的状况。我们牢记于心。更多关于状态码点击 ➡

Remote Address

顾名思义，这个远程地址说的就是请求的目标地址，也是响应的源地址，直接说就是服务器的 IP 地址。在客户端看是服务器的地址，在服务器上看就是客户端地址，这是相互的，很容易理解。一般与代理会扯上关系。

如果使用浏览器直接访问某个网站，那么网站的 web 服务器（Nginx、Apache等）就会把 REMOTE_ADDR 设为客户端的 IP 地址。

如果我们给浏览器设置代理，我们访问目标网站的请求会先经过代理服务器，然后由代理服务器将请求转化到目标网站。那么网站的 web 服务器就会把 REMOTE_ADDR 设为代理服务器的 IP。

Referrer Policy

在页面引入图片、JS 等资源，或者从一个页面跳到另一个页面，都会产生新的 HTTP 请求，浏览器一般都会给这些请求头加上表示来源的 Referrer 字段。Referrer 在分析用户来源时很有用，有着广泛的使用。但 URL 可能包含用户敏感信息，如果被第三方网站拿到很不安全（例如之前不少 Wap 站把用户 SESSION ID 放在 URL 中传递，第三方拿到 URL 就可以看到别人登录后的页面）。之前浏览器会按自己的默认规则来决定是否加上 Referrer。 - Referrer Policy 介绍 -Jerry Qu

这个字段就是控制 referer 字段携带的内容，它会有这些政策：

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

  • no-referrer

    整个 Referer 首部会被移除。访问来源信息不随着请求一起发送。

  • no-referrer-when-downgrade（默认值）

    在没有指定任何策略的情况下用户代理的默认行为。在同等安全级别的情况下，引用页面的地址会被发送 (HTTPS->HTTPS)，但是在降级的情况下不会被发送 (HTTPS->HTTP)。

  • origin

    在任何情况下，仅发送文件的源作为引用地址。例如 https://example.com/page.html 会将 https://example.com/ 作为引用地址。

  • origin-when-cross-origin

    对于同源的请求，会发送完整的 URL 作为引用地址，但是对于非同源请求仅发送文件的源。

  • same-origin

    对于同源的请求会发送引用地址，但是对于非同源请求则不发送引用地址信息。

  • strict-origin

    在同等安全级别的情况下，发送文件的源作为引用地址 (HTTPS->HTTPS)，但是在降级的情况下不会发送 (HTTPS->HTTP)。

  • strict-origin-when-cross-origin

    对于同源的请求，会发送完整的 URL 作为引用地址；在同等安全级别的情况下，发送文件的源作为引用地址 (HTTPS->HTTPS)；在降级的情况下不发送此首部 (HTTPS->HTTP)。

  • unsafe-url

    无论是同源请求还是非同源请求，都发送完整的 URL（移除参数信息之后）作为引用地址。

更多可查看 MDN Referrer-Policy

小结

现在我们可以弄清楚前面的图里到底是怎么一回事啦

heneral1.png

想象一下看到这些会遇到什么呢？一个开了 https 的域名，我们要对这个 url 地址进行获取动作，拿到这个地址对应的资源，现在这个动作成功啦（200），资源部署在IP为 198.18.0.42:443 的服务器下，当在这个资源里点击链接请求其他资源的时候，同源就给全部，不同源就给源，不会在https到http的传输中加入 referer 字段。

情况一：remote address 不存在

这种情况是请求了本地资源，也即是request url 指向本地比如上面的图中，字体文件指向的是chrome 扩展程序内的某个扩展文件地址，因为是在本地所以没有remote address。

情况二：只有Request URL 和 Referrer Policy

当我们本地起一个服务，然后在浏览器访问后，关闭服务，刷新页面，得到如下结果：

情况2.png

未完待续......

我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿。

avatar
文章
阅读
粉丝