307 Переспрямування під час завантаження analytics.js у Chrome

Я створюю веб-додаток і використовую Google Analytics (analytics.js) для аналізу. Нещодавно я помітив, що аналітика не працює належним чином у Chrome.

Я завантажую аналітику, використовуючи стандартний фрагмент коду в окремому модулі та включений через requirejs. Я перевірив, що цей сценарій працює належним чином, і виконує фрагмент аналітики.

Коли я перевіряю мережевий трафік у Firefox, я бачу, що сценарій аналітики завантажується з Google, як очікувалося (відповідь HTTP 200):

Однак, коли я запускаю ту саму сторінку в Chrome, я отримую відповідь HTTP 307, що вказує на about: blank, а аналітика не запускається:

Однак, якщо я встав URL-адресу аналітики безпосередньо в адресний рядок Chrome, скрипт знайдено. Будь-які ідеї, що тут відбувається, або як це виправити?

307 Internal Redirectз Non-Authorative-Reason: Delegateвказує на те, що запит було перехоплено та змінено (перенаправлено) розширенням Chrome через API веб- запиту або декларативного розширення webRequest .

Ви можете дізнатись, яке розширення спричинило переспрямування наступним чином:

1. Відвідайте chrome://net-internals/#events
2. Запустіть запит (у вашому випадку Google Analytics).
3. Поверніться на chrome://net-internals/#eventsвкладку та знайдіть URL_REQUEST, який відповідає вашому запиту (ви можете використовувати поле пошуку для фільтрування пошуку).
4. Клацніть на запис, щоб відобразити журнал праворуч. Ви побачите назву розширення, ідентифікатор розширення та іншу інформацію про запит:

t = 7910 [st = 0] + ЗАПИТАТИ_АЛІВ [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"
                 -> пріоритет = "НИЗЬКИЙ"
                 -> url = "https://www.google-analytics.com/analytics.js"
t = 7915 [st = 5] URL_REQUEST_REDIRECT_JOB
                   -> причина = "Делегувати"
t = 7915 [st = 5] URL_REQUEST_FAKE_RESPONSE_HEADERS_CREATED
                   -> HTTP / 1.1 307 Внутрішня перенаправлення
                       Місцезнаходження: приблизно: порожнє
                       Неавторитетна причина: делегат

У цьому прикладі журналу розширення з іменем "[Назва розширення]" та ідентифікатором розширення "ebmlimjkpnhckbaejoagnjlgcdhdnjlb" перенаправило запит. Після пошуку імені та / або ідентифікатора розширення ви можете відвідати chrome://extensionsта вимкнути або видалити розширення, яке змінило запит.

У моєму випадку причина переспрямування 307 була більш прозаїчною. За звичкою використовувати URL-адреси , що відносяться до протоколів, я видалив протокол із URL-адреси в сценарії вбудовування Google Universal Analytics, змінивши https://www.google-analytics.com/analytics.jsна //www.google-analytics.com/analytics.js.

Наприклад ( не намагайтеся це робити вдома ):

(функція (i, s, o, g, r, a, m) {i ['GoogleAnalyticsObject'] = r; i [r] = i [r] || function () {(i [r] .q = i [r] .q || []). push (аргументи)}, i [r] .l = 1 * нова дата (); a = s.createElement (o), m = s.getElementsByTagName (o) [ 0]; a.async = 1; a.src = g; m.parentNode.insertBefore (a, m)}) (вікно, документ, 'скрипт', ' https: //www.google-analytics.com/analytics .js ',' ga ');

Це недоцільно, оскільки Google, очевидно, обслуговує сценарій та запити на відстеження лише через https. Отже, видалення протоколу спричиняє переспрямування як при першому вбудовуванні сценарію, так і в будь-якому (!) Наступному запиті відстеження. Крім того, як зазначив Пол Ірланд в оновленні свого канонічного допису про URL-адреси , що стосуються протоколів , цей прийом більше не заохочується або насправді має переваги:

Зараз, коли SSL заохочується для всіх і не турбується щодо продуктивності, цей метод тепер є анти-шаблоном. Якщо потрібний вам ресурс доступний на SSL, завжди використовуйте https: // актив.

У моєму випадку в моєму браузері активовано UBlock Origin. Після відключення або дозволу сайту внутрішні перенаправлення припиняються