Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

307 Redirect when loading analytics.js in Chrome

I'm building a web app and using Google Analytics (analytics.js) for analytics. I recently noticed that analytics aren't working properly in Chrome.

I'm loading analytics using the standard code snippet in a separate module and included via requirejs. I've verified that this script runs as expected and executes the analytics snippet.

When I inspect network traffic in Firefox, I can see that the analytics script is loaded from Google as expected (HTTP 200 response):

enter image description here

However, when I run the exact same page in Chrome, I get an HTTP 307 response pointing to about:blank, and analytics does not run:

enter image description here

However, if I paste the analytics URL directly into the Chrome address bar, the script is found. Any ideas what's going on here, or how to fix it?

like image 711
Benj Avatar asked Jan 14 '15 14:01

Benj


2 Answers

307 Internal Redirect with Non-Authorative-Reason: Delegate indicates that the request was intercepted and modified (redirected) by a Chrome extension via the webRequest or declarative webRequest extension APIs.

You can find out which extension triggered the redirect as follows:

  1. Visit chrome://net-internals/#events
  2. Trigger the request (google analytics, in your case).
  3. Go back to the chrome://net-internals/#events tab and look for a URL_REQUEST matching your request (you can use the searchbox to filter the search).
  4. Click on the entry to show the log at the right side. You will see the extension name, extension ID and other information about the request:
 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 

In this log sample, an extension with name "[Name of extension]" and extension ID "ebmlimjkpnhckbaejoagnjlgcdhdnjlb" redirected the request. After finding the extension name and/or ID, you can visit chrome://extensions and disable or remove the extension that modified the request.

like image 154
Rob W Avatar answered Sep 21 '22 11:09

Rob W


In my case, the reason for the 307 redirect was more prosaic. Out of habit of using protocol-relative URLs, I've removed the protocol from the URL in the embedding script of the Google Universal Analytics, changing https://www.google-analytics.com/analytics.js to //www.google-analytics.com/analytics.js.

For example (don't try this at home):

(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

This is inadvisable since Google apparently serves the script and tracking requests only over https. So removing the protocol causes a redirect both when first embedding the script as well as in any(!) subsequent tracking request. In addition, as stated by Paul Irish in an update to his canonical post about protocol-relative URLs, this technique is no longer encouraged or indeed has merit:

Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the https:// asset.

like image 39
Boaz Avatar answered Sep 18 '22 11:09

Boaz