Супер медленные предполетные опционы только в Chrome

Недавно я боролся с сверхъестественной проблемой, происходящей только в Chrome: поскольку мой API (NodeJS) находится на другом подобласте, мне нужно использовать CORS для его доступа из моего интерфейса (EmberJS).

Он работает очень хорошо, но я очень часто (95% случаев) имеет очень медленные запросы OPTIONS, задерживая любые вызовы API примерно на 3 секунды.

Большую часть этого времени тратится на загрузку пустого контента:

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

Несколько других вещей, которые я пробовал:

Я пробовал это с Firefox и Safari и не получал никаких задержек.
Я пробовал это локально или в производстве, экспериментируя с той же задержкой.
Я пробовал это с помощью режима инкогнито (без расширений), и у меня такая же проблема.

Мы используем на back-end NodeJS пакет CORS.

Теперь я не знаю, проблема в Chrome 60, NodeJS, CORS или EmberJS + jQuery.

Кто-нибудь тоже испытал это?

Ответ 1

Как примечание: Кажется, ошибка хром

Я воспроизвел проблему, используя сервер с двумя именами DNS, используя службу в уникальном домене

https://domain1.com  --> https://domain1.com (No CORS, no delay)
https://domain2.com  --> https://domain1.com (CORS, delay)

Это точно тот же сервис, отвечающий двум именам, поэтому я тестирую точно такой же запрос, код клиента и сервера (имена DNS взаимозаменяемы)

Протестировано с помощью

Chrome 61.0.3163.100 (Windows) → DELAY
Chrome 62.0.3202.84 (Android) → DELAY
Chrome 62.0.3202.84 (iOS-Ipad) → ОК!!!
Firefox → OK
Edge → OK

Обходной путь (в моем случае). Создайте прокси-сервер в моем хосте, чтобы ответить на тот же DNS-источник и избежать CORS

Ответ 2

Я пытаюсь отлаживать это и , кажется, хром-ошибка, поскольку мы столкнулись с той же проблемой.

Для справки я подал отчет об ошибке на хром здесь: Предварительные запросы CORS и последующие запросы очень медленны только в Chrome

Я добавляю это здесь, чтобы помочь остановить больше разработчиков, проводящих пол дня, исследуя его;) Будет обновляться, поскольку мы здесь больше из Chromium.

Ниже приведен обзор отчета об ошибке:

UserAgent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

Шаги по воспроизведению проблемы:

Имейте app.domain.com
Элемент списка
Есть api.domain.com
Включить CORS для API для доступа
Проверяйте ответы в DevTools, см. OPTIONS и GET-запросы занимают до 300 мс +

Какое ожидаемое поведение?

Тайм-ауты ответа должны быть точными.

Что пошло не так?

Мы используем микросервисы Go и заметили большое несоответствие в времени между браузерами - хром был самым медленным до величины 100x.

когда мы проверили тайминги из бэкэнд, ответы занимают не более 10 мс, причем большинство из них составляют 1 мс. При проверке времени при devtools одни и те же ответы приходили в ~ 100 мс ~ 1 с.

Раньше это работало?

N/A

Версия Chrome: 63.0.3239.132 Канал: стабильный Версия ОС: 10.0 Версия Flash:

В Firefox (и любом другом браузере) точно такие же запросы возвращаются в ~ 1-20 мс, как ожидалось.

При попытке дальнейшего диагностирования мы использовали Telerik Fiddler для проверки фактического времени ответа сети и подтвердили, что они были отправлены и получены Chrome в течение наших ожидаемых сроков. Единственный вывод, который мы могли бы сделать, заключается в том, что что-то внутреннее в Chrome замедляет обработку этих запросов.

Мы пробовали все перестановки chrome://flags#out-of-blink-cors и chrome://flags#enable-site-per-process, которые являются двумя опциями, которые мы заметили, которые кажутся смутно релевантными. Кажется, ничего не помогло.

Мы также обнаружили много статей о переполнении стека о похожих проблемах, которые упоминают, что это ошибка Chrome, но я не смог найти ее здесь:

Мы только что протестировали Chrome на MacOS и, похоже, это не проблема, поэтому он может быть ограничен Windows.

Chrome:

Край:

Firefox: