我是这样发现ISP劫持HTTP请求的

IP正确并且为我方服务器IP确认并非为DNS攻击。

With this data in mind, Chrome, starting with version 55, intervenes on behalf of all users when we detect this known-bad pattern by changing how document.write() is handled in Chrome (See Chrome Status). Specifically Chrome will not execute the <script> elements injected via document.write()when all of the following conditions are met:

1. The user is on a slow connection, specifically when the user is on 2G. (In the future, the change might be extended to other users on slow connections, such as slow 3G or slow WiFi.)
2. The document.write() is in a top level document. The intervention does not apply to document.written scripts within iframes as they don't block the rendering of the main page.
3. The script in the document.write() is parser-blocking. Scripts with the 'async' or 'defer' attributes will still execute.
4. The script is not hosted on the same site. In other words, Chrome will not intervene for scripts with a matching eTLD+1 (e.g. a script hosted on js.example.org inserted on www.example.org).
5. The script is not already in the browser HTTP cache. Scripts in the cache will not incur a network delay and will still execute.
6. The request for the page is not a reload. Chrome will not intervene if the user triggered a reload and will execute the page as normal.

Third party snippets sometimes use document.write() to load scripts. Fortunately, most third parties provide asynchronous loading alternatives, which allow third party scripts to load without blocking the display of the rest of the content on the page.

Kevin@Fundebug:

版权声明

评论 ( 0 )
暂无评论

• 二维码

扫一扫，手机上览此页。

扫一扫，手机浏览 前端网（QDFuns） 新浪微博，也可直接 点击这里网页访问，当然更希望您能关注我们，第一时间了解最新活动和动态。

• 返回顶部