! я вижу это так: даже если при обломе JS твоя форма позволяет пользователю отправить данные во фрейм, то на этом всё и закончится. потому что возврат во фрейме на той же странице тебе обработать нечем. вывод: это не graceful degradation. ты прячешь фрейм, да?
знаешь ли ты, что в случае если страница не получена, а тестовый пользователь попросил у браузера "исходный код страницы", то скорее всего будет повторный запрос (и новый результат)? и поэтому может выглядеть как будто всё хорошо https://stackoverflow.com/questions...w-source-be-set-to-not-make-a-new-get-request --- Добавлено --- меня смутила фраза "на этой самой странице". яподумал, что URL страницы не меняется ну собсна, тогда изначальное предположение в силе: твой "грейсфул" относится только к отправке. в то время как я спрашивал про страницу возврата — достаточно ли там серверного рендеринга чтобы страница была не белой?
Копию html-кода сохраняет сервер. PHP: ob_start(); ...; file_put_contents('...', ob_get_contents()); ob_end_flush(); Пользователь видит белую страницу вместо страницы отправки. Повторюсь, что до возврата из банка не доходит. Пользователь тупо не попадает в банк. --- Добавлено --- А вот отказ от googleapis не помог. Репорты продолжают приходить.
Я спрашиваю потому что обращения в банк ещё не было до проблемной страницы, то о нём вроде и упоминать было незачем. Давай суммируем: Есть финальная страница оформления заказа (чекаут). Она приходит с твоего сервера, а не жс её генерит. На этот момент получено достаточно информации, чтобы отправить запрос на оплату дальше на сторонний сайт (банк/агрегатор/не важно). Простого редиректа было бы достаточно, НО пользователь должен подтвердить факт намерение оплатить — неважно с жс или без, он кликает [ Оплатить ] и погнали. Но почему-то этой страницы пользователь иногда не видит. Правильно? Я подозреваю, что твои логи содержат только успешные ответы, в то время как запрос на саму эту страницу мог не поступать. Как такое отследить? Не знаю, пытаться полностью цепочку шагов логировать по сешн айди или ещё чему-то уникальному. Потом искать пересечения с репортами. Другая идея: страница не отрисовывается, если обломался JS. Нае*нулся по ошибке, а не отключен — есть разница. Если твой "грейсфул" это нечто внутри <noscript> то это блин не выход, т.к. ЖС не отключен и содержимое носкрипт не будет работать. Поэтому спрашиваю про "достаточно ли серверного рендеринга чтобы страница была не белой". --- Добавлено --- инлайн "display: none" а затем в JS замена на "display: block" ?
Меня смущает формулировка "подтвердить факт оплаты". На этом этапе подтверждать нечего - пользователь еще ничего не оплатил. Он должен сначала попасть на страницу банка, сделать оплату, и уже потом банк вернет пользователя на страницу интернет-магазина, что и будет подтверждением факта оплаты. А так да, все верно. Давай скажем так - бывают проблемные чекауты (белая страница), и успешные чекауты (переадресация на банк). Так вот, проблемные чекауты успешно логируются. Сервер возвращает 200 с 18кб тела за 0.6-0.7 секунды. И эти записи в логах ничем не отличаются от успешных чекаутов (такие же показатели). В моменты проблемных чекаутов также нет спайков, что исключает проблему нагрузки. Увы, но страница идеально рендерится. <noscript> тэгов нет. Отвечая на твой вопрос - серверного рендеринга достаточно. Появилась новая идея - все проблемные чекауты за последнюю неделю были с IP адресов одного и того же провайдера. Может быть дело в нем. Но проверить это будет очень сложно.
Да никак. Логи пустые, снепшоты исправные, избавился от google fonts, google maps, facebook sdk и других сторонних сервисов. Без результатов. Сейчас подключил sentry.io, но это скорее от безысходности, а не целенаправленная мера. Копаю дальше.