2015-01-14 7 views
51

私はウェブアプリケーションを構築しており、分析にはGoogleアナリティクス(analytics.js)を使用しています。私は最近、分析がChromeで適切に機能していないことに気付きました。307 Chromeでanalytics.jsを読み込むときのリダイレクト

私は別のモジュールに標準コードスニペットを使用してanalyticsを読み込み、requirejsを使用して読み込みます。私はこのスクリプトが期待どおりに実行され、分析スニペットが実行されることを確認しました。

私はFirefoxでのネットワークトラフィックを検査するとき、私は予想通りの分析スクリプトは、Googleからロードされていること(HTTP 200応答)を見ることができます:

enter image description here

しかし、私は正確に同じページを実行Chromeは、私は約を指しているHTTP 307応答を取得:空の、そして分析は実行されません:

enter image description here

をしかし、私は直接クロームアドレスに分析URLを貼り付けた場合バー、スクリプトが見つかりました。ここで何が起こっているのか、それを修正する方法は? Non-Authorative-Reason: Delegate

答えて

132

307 Internal Redirect要求が傍受さwebRequest又はdeclarative webRequest拡張APIを介してChrome拡張機能によって(リダイレクト)変更されたことを示しています。

あなたは次のようにリダイレクトをトリガした拡張子を見つけることができます。

  1. ログインchrome://net-internals/#events
  2. トリガ要求(あなたのケースでは、分析をグーグル)。
  3. chrome://net-internals/#eventsタブに戻り、リクエストに一致するURL_REQUESTを探します(検索ボックスを使用して検索をフィルタリングできます)。
  4. エントリをクリックすると、右側にログが表示されます。あなたが要求に関する拡張名、拡張子の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 = "extension [Name of extension]" 
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 = "https://www.google-analytics.com/analytics.js" 
t=7915 [st=5]  URL_REQUEST_REDIRECT_JOB 
        --> reason = "Delegate" 
t=7915 [st=5]  URL_REQUEST_FAKE_RESPONSE_HEADERS_CREATED 
        --> HTTP/1.1 307 Internal Redirect 
         Location: about:blank 
         Non-Authoritative-Reason: Delegate 

、名前の拡張子「[拡張子の名前]」と拡張ID「ebmlimjkpnhckbaejoagnjlgcdhdnjlb」要求をリダイレクト。内線番号および/またはIDを見つけたら、chrome://extensionsにアクセスして、要求を変更した内線番号を無効または削除することができます。

+9

ブリリアント。私はこの分析が可能であるとは考えていませんでした。それは、(....ドラムロール、してください...)の拡張機能になって、分析をブロックします。それはまさにそれがやろうとしていることをしていた... – Benj

+2

あなたは、私の日を作った! ;) – 23tux

+0

これは信じられないほどです。強くありがとう!私はAdblockが私のために投稿されたスニペットと同じ場所にあることを知っています。シークレットモードで明白な兆候が見られない場合はどういう意味ですか? 'REQUEST ALIVE'、' URL_REQUEST_DELEGATE'(no +/details、dt = 0)から開始ジョブ/リダイレクトジョブにまっすぐ進みます。いずれにせよ、この重い洞察に感謝します! –

4

私の場合、307リダイレクトの理由はより懐古的でした。 protocol-relative URLsを使用する習慣から、Googleユニバーサルアナリティクスの埋め込みスクリプトのURLからプロトコルを削除しました。https://www.google-analytics.com/analytics.js//www.google-analytics.com/analytics.jsに変更しました。例えば

がホームでこれを試していない):

(関数(I、S、O、G、R、M){iは[ 'GoogleAnalyticsObject'] = R (引数)}、i [r] .l = {[r] .q} a.async = 1; a.src = g; m.parentNode.insertBefore(a、m); * new Date(); a = s.createElement(o)、 m = s.getElementsByTagName(o)[0] ) })(ウィンドウ、ドキュメント、 'スクリプト'、 ' https: //www.google-analytics.com/analyticsjs '、' ga ');

これは、Googleが明らかにhttpsでのみスクリプトとトラッキングリクエストを提供するため、これはお勧めできません。したがって、プロトコルを削除すると、最初にスクリプトを埋め込むときと、後続の追跡要求があるとき(!)の両方でリダイレクトが発生します。彼のcanonical post about protocol-relative URLsに更新してポール・アイリッシュにより述べたように加えて、この技術は、もはや奨励または実際にメリットがありますされています

今でSSLが皆のために奨励されており、パフォーマンスの懸念を持っていない、この技術ではありません今はアンチパターンです。必要なアセットがSSLで使用できる場合は、常にhttps://アセットを使用します。

関連する問題