关于java:用了这么久的-Chrome你不会还没掌握这个功能吧

6次阅读

共计 2074 个字符,预计需要花费 6 分钟才能阅读完成。

背景

最近在做公司外部的我的项目,测试在测试过程中发现接口申请实现之后没有带过相干的数据,随后关上控制台查看是否是接口问题,发现接口报如下的异样,状态码是 200,但返回的内容显示不进去,而且控制台是提前关上 Preserve log 的,实践上之前发送的申请是应该会有记录的,但后果确看不到 Response。

通过排查过后发现是对 Preserve log 的了解有偏差,由此引发了接下来的摸索。

Preserve log 简介

To save requests across page loads, check the Preserve log checkbox on the Network panel. DevTools saves all requests until you disable Preserve log.

依照 Chrome 官网文档的介绍,Preserve log 如果勾选,在跨页面加载申请时,会保留之前的所有申请,目标是为了不便开发同学排查一些跨站申请是接口的一些问题,比方数据比照等。

然而官网没有写的是如果想要看到返回的 Response,你必须在页面跳转之前先提前点击查看该接口,能力在跳转之后看到之前的接口返回的信息,对于那些没有点击过的接口,在下一个页面中是查看不到返回的后果的,Response 看到的信息跟上图是相似的,都会有一个独特的报错“Failed to load response data”。

那是不是所有的浏览器都这样呢?还是只是 Chrome 一家是这种状况?接下来对 Preserve log 的兼容性做了一个剖析。

Preserve log 兼容性

咱们选取三个浏览器做样本,别离是 Chrome、Safari、Firefox。验证的步骤如下:

  • 选取一个能从 A 网站跳转到 B 网站的页面
  • 关上控制台,勾选 Preserve log 选项
  • 刷新页面,找任意一个 A 页面的申请关上,其它的申请不点击
  • 点击 A 网站 跳转到 B 网站的链接,在 B 网站查看之前 A 网站的申请数据

试验后果如下:

Chrome

在 Chrome 中,试验后果跟咱们之前看到的是一样的,只会对点击的申请做保留,未点击的申请不会展现 Response。


Safari

在 Safari 中,Preserve log 的体现跟 Chrome 是统一的,只有点击之后的接口才会保留 Response,未点击的会展现“尝试载入资源时产生谬误”,查看不了相应的后果,Safari 有个益处是,当跳转到 B 网站之后,控制台中 A 网站的申请都置灰了,会不便察看和操作。

Firefox

在 Firefox 中,如果勾选了 Persist Logs 之后,申请是会被残缺的保留下来的,在下一个页面中能看到上一个页面残缺的申请和返回的信息,阐明 Firefox 是不受限制的。


Preserve log 为什么不会残缺保留申请日志

通过以上的剖析会发现,不同浏览器对保留日志的解决是不一样的。Chrome 这种解决形式在 issue 上也引发了宽泛的探讨,而且还是一个历史悠久的 issue,总结下来大抵观点分为两派。

拥护方:

  • NetWork 呈现的谬误很容易让他人误以为谬误呈现在服务端,引起误会
  • 如果重定向产生的十分快,用户是很难去点击链接的,所以还得借助第三方工具帮忙
  • Preserve log 有歧义,明明是保留日志,但理论的后果确没有像 Charles 等工具一样残缺的保留日志

同意方(chromium 开发者):

  • 这是“low overhead”的后果,Response 并不会传到 DevTools,除非用户想要查看并点击它,目标是为了防止扭曲测量后果
  • 如果将所有的 Response 都保留在 DevTools,则会减少很多的不必要的内容,如果用户点击了好多的跨站链接,结果不可设想
  • 这是一种折中最好的计划,既兼顾了易用性,也兼顾了灵活性

两方观点各有各的的情理,但我认为,Chrome 应该把这个权限放开给开发者,因为原本 DevTools 就是给开发者用的,Preserve log 并没有解决开发者跨站申请须要查看原链接的诉求,保留日志的本意应该是要保留所有的 Request 和 Response 信息,而不应该做阉割版本,应该由开发者去管制是否开启这一选项,并承当相应的后果。

不然有的时候还得通过第三方工具进行抓包或者像 issue 中讲到的那样,须要在代码层面做解决,这无疑让一个原本很简略的性能变得复杂化。

浏览器厂商的改良节奏

issue 中也有一些 Chromium 的反馈,原来认为这个需要没有必要做,而且优先级比拟低,17 年的时候因为优先级和资源问题敞开了,但最近看如同又重启了,状态变成了 Open,期待之后的版本可能改善这个问题。

总结

以上是对 Preserve log 做了一个简略的介绍,如果在开发中真的遇到了下面的问题,解决方案能够思考用以下几种计划:

1、应用 Firefox 浏览器(目前貌似用的人比拟少)
2、如 issue 中所说,通过在代码中打点来进行调试,“window.onunload = function() {debugger;}”,但理论利用起来不太方便使用 Charles 等抓包工具进行抓包

作者:ES2049
链接:https://segmentfault.com/a/11…

正文完
 0