在Chrome中加载analytics.js时redirect307
我正在构build一个Web应用程序，并使用Google Analytics（analytics.js）进行分析。 我最近注意到分析在Chrome中无法正常工作。
我使用标准的代码片段在一个单独的模块中加载分析，并通过requirejs进行加载。 我已validation此脚本按预期运行并执行分析片段。
当我检查Firefox中的networkingstream量时，我可以看到分析脚本按预期从Google加载（HTTP 200响应）：
但是，当我在Chrome中运行完全相同的页面时，我得到一个指向about：blank的HTTP 307响应，分析不会运行：
但是，如果我将分析url直接粘贴到Chrome地址栏中，则会find该脚本。 任何想法发生在这里，或如何解决？
307 Internal Redirect使用Non-Authorative-Reason: Delegate 307 Internal Redirect Non-Authorative-Reason: Delegate表示请求被Chrome扩展程序通过webRequest或声明式webRequest扩展API截获和修改（redirect）。
你可以找出哪个扩展触发了redirect，如下所示：
- 访问
chrome://net-internals/#events - 触发请求（谷歌分析，在你的情况）。
- 回到
chrome://net-internals/#events选项卡，并寻找与您的请求相匹配的URL_REQUEST（您可以使用search框来过滤search）。 - 点击条目，在右侧显示日志。 您将看到有关请求的分机名称，分机ID和其他信息：
t = 7910 [st = 0] + REQUEST_ALIVE [dt = 6]
t = 7910 [st = 0] + URL_REQUEST_DELEGATE [dt = 5]
t = 7910 [st = 0] DELEGATE_INFO [dt = 5]
- > delegate_info =“扩展名[扩展名]”
t = 7915 [st = 5] CHROME_EXTENSION_REDIRECTED_REQUEST
- > extension_id =“ebmlimjkpnhckbaejoagnjlgcdhdnjlb”
t = 7915 [st = 5] -URL_REQUEST_DELEGATE
t = 7915 [st = 5] + URL_REQUEST_START_JOB [dt = 1]
- > load_flags = 339804160（BYPASS_DATA_REDUCTION_PROXY | MAYBE_USER_GESTURE | REPORT_RAW_HEADERS | VERIFY_EV_CERT）
- > method =“GET”
- > priority =“LOW”
- > url =“analytics.js”
t = 7915 [st = 5] URL_REQUEST_REDIRECT_JOB
- > reason =“委托”
t = 7915 [st = 5] URL_REQUEST_FAKE_RESPONSE_HEADERS_CREATED
- > HTTP / 1.1 307内部redirect
位置：约：空白
非权威原因：代表
在此日志示例中，名称为“[扩展名]”和扩展名“ebmlimjkpnhckbaejoagnjlgcdhdnjlb”的扩展名将该请求redirect。 find扩展名和/或ID后，您可以访问chrome://extensions并禁用或删除修改请求的扩展名。
就我而言，307redirect的原因更为平淡无奇。 出于使用协议相关URL的习惯，我已经从Google Universal Analytics的embedded脚本中的URL中删除协议，将analytics.js更改为analytics.js 。
例如（ 不要在家里尝试 ）：
（函数（i，s，o，g，r，a，m）{i ['GoogleAnalyticsObject'] = r; i [r] = i [r] || function（）{（i [r]新的Date（）; a = s.createElement（o），m = s.getElementsByTagName（o）[i] [r] .q || []） 0]; a.async = 1; a.src = g; m.parentNode.insertBefore（a，m）}）（window，document，'script'，'
https：//www.google-analytics.com/analytics的.js'， 'GA'）;
这是不明智的，因为谷歌显然只通过https服务脚本和跟踪请求。 因此，在第一次embedded脚本时以及在任何（！）后续跟踪请求中，删除协议都会导致redirect。 此外，正如保罗·爱尔兰在其关于协议相关URL的规范文章的更新中所述，这种技术不再被鼓励或者确实具有优点：
既然SSL受到鼓励，并且没有性能问题，现在这种技术是反模式。 如果您需要的资产在SSL上可用，请始终使用https：//资产。
