307 Перенаправление при загрузке analytics.js в Chrome

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

Я загружаю аналитику с помощью стандартного фрагмента кода в отдельный модуль и включаю через requirejs. Я проверил, что этот script работает как ожидалось и выполняет фрагмент аналитики.

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

Однако, когда я запускаю ту же самую страницу в Chrome, я получаю ответ HTTP 307, указывающий примерно: blank и аналитика не запускается:

Однако, если я вставляю URL-адрес аналитики непосредственно в адресную строку Chrome, будет найден script. Любые идеи, что здесь происходит, или как это исправить?

Ответ 1

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

Вы можете узнать, какое расширение вызвало перенаправление следующим образом:

Посетите chrome://net-internals/#events
Запустите запрос (Google Analytics, в вашем случае).
Вернитесь на вкладку chrome://net-internals/#events и найдите URL_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

В этом примере журнала расширение с именем "[Имя расширения]" и идентификатором расширения "ebmlimjkpnhckbaejoagnjlgcdhdnjlb" перенаправил запрос. После нахождения имени расширения и/или идентификатора вы можете посетить chrome://extensions и отключить или удалить расширение, которое изменило запрос.

Ответ 2

В моем случае причина редиректа 307 была более прозаичной. Из-за привычки использовать URL-адреса, относящиеся к протоколу, я удалил протокол из URL-адреса в скрипте встраивания Google Universal Analytics, изменив https://www.google-analytics.com/analytics.js на //www.google-analytics.com/analytics.js.

Например (не пытайтесь сделать это дома):

(function (i, s, o, g, r, a, m) {i ['GoogleAnalyticsObject'] = r; я [r] = я [r] || function() {(i [r].q = я [r].q || []). push (arguments)}, я [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)}) (окно, документ, "скрипт", " ~~https:~~//www.google-analytics.com/analytics".js', 'га');

Это нежелательно, поскольку Google, по-видимому, обслуживает сценарии и отслеживает запросы только через https. Таким образом, удаление протокола вызывает перенаправление как при первом встраивании скрипта, так и при любом (!) Последующем запросе отслеживания. Кроме того, как заявил Пол Ирриш в обновлении своего канонического поста об URL-адресах, связанных с протоколом, этот метод больше не поощряется или действительно имеет свои достоинства:

Теперь, когда SSL поощряется для всех и не имеет проблем с производительностью, этот метод теперь является анти-паттерном. Если нужный вам ресурс доступен по SSL, всегда используйте https://asset.

Ответ 3

В моем случае в моем браузере активирован UBlock Origin. После отключения или авторизации на сайте внутренние перенаправления прекратились