Периодически обнаруживаю в интерактивных веб-интерфейсах разных порталов (магазины, банки, госконторы и т.п.) различные глюки поведения. Иногда это обычное искажение разметки, текста или изображений, но бывают и ошибки, характерные для неправильной работы исполняемого кода (серверного или клиентского JS). Пишу в поддержку, там первым делом советуют "почистить кэш и куки, перезапустить браузер, попробовать другой браузер". Разумеется, это никогда не помогало. Объясняю, что проявление характерно в первую очередь для ошибок в логике работы кода, или для порчи записей в БД, но там настаивают, что нужно "протереть фары, попинать колеса".

Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно? Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно? Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно? Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?
Конечно могут.
Классический сценарий: сервер отдаёт CSS или JS динамически — генерирует на лету. Ленивый разработчик не задуряется подготовкой хидера Content-Length.
Без него клиент (или прокси) при обрыве соединения получает неполный файл, но полагает его валидным.
Побитый файл застревает в кэше, и при продолжении использования влияет на отображение. Стили не применяются, JS пытается вызвать функции, которых нет.
Всё это лечится раз и навсегда на серверной стороне аккуратной отдачей Content-Length: тогда неполный ответ не считается окончательным, и клиент будет пробовать докачать (или перезакачать) побитый файл.
То есть однократный разрыв соединения при загрузке перестаёт портить дальнейшую навигацию.

Второй классический сценарий — криворукие программисты не понимают, как работает кэш. Сначала они выставляют статическим ресурсам типа JS или CSS Expiration:never, потому что видят, как их загрузка (даже с conditional get) на каждый чих тормозит работу приложения. А потом они заливают на сервер новые версии с теми же именами файлов, и мучительно борются с тем, что теперь у клиента половина скриптов от версии 1.0.6, а половина — от 1.0.8.

Правильная работа, конечно же, выставлять статике Expiration:never, но добавлять версию ресурса в URL. Тогда мы имеем immediate expiration при изменениях.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно?

Конечно могут, но это не исключает ошибок в коде, в идеале код должен эти особенности обрабатывать. Есть один довольно серьезный сервис, которым пользуюсь, так он мне периодически выдает белую страницу, пока не почищу данные, причем только в ФФ, но не в хроме.

ЕМ>Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?

А это само собой, и не обязательно только предписано. "Попробуйте выключить и включить", "почистить куки" и т.п.(сброс до детерминированного состояния) устраняет обычно бОльшую часть глюков, пусть и, возможно, временно, но как раз быстрое решение техподу и нужно.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного?

Могут. Например один файл у тебя в кеше старой версии, а другой загрузился новой версии и пытается использовать функции из старого, как будто это функции из нового.

EM>Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно?

На мой взгляд маловероятно. Но, возможно, я ошибаюсь. В своих сайтах я всегда слежу за тем, чтобы проблем с кешированием не было, но вполне могу себе представить ситуации, когда они есть.

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

EM>Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?

Это само собой. Когда к провайдеру звонишь и тебя не пускают дальше, пока не перезагрузишь компьютер.

Здравствуйте, Sinclair, Вы писали:

S>Классический сценарий: сервер отдаёт CSS или JS динамически — генерирует на лету. Ленивый разработчик не задуряется подготовкой хидера Content-Length.
S>Без него клиент (или прокси) при обрыве соединения получает неполный файл, но полагает его валидным.
S>Побитый файл застревает в кэше, и при продолжении использования влияет на отображение. Стили не применяются, JS пытается вызвать функции, которых нет.

Ты что-то путаешь. Если не указывается длина, используется chunked encoding. У каждого куска указывается длина отдельно и в конце кусок нулевой длины, как маркер конца. Полагать неполный файл валидным невозможно.

S>Второй классический сценарий — криворукие программисты не понимают, как работает кэш. Сначала они выставляют статическим ресурсам типа JS или CSS Expiration:never, потому что видят, как их загрузка (даже с conditional get) на каждый чих тормозит работу приложения. А потом они заливают на сервер новые версии с теми же именами файлов, и мучительно борются с тем, что теперь у клиента половина скриптов от версии 1.0.6, а половина — от 1.0.8.

S>Правильная работа, конечно же, выставлять статике Expiration:never, но добавлять версию ресурса в URL. Тогда мы имеем immediate expiration при изменениях.

Согласен, всё так. Главное не забыть про это, когда один ресурс ссылается на другой (например css import). А в идеале это всё должен делать фреймворк. Тогда вместо версии ресурса можно добавлять его хеш-сумму.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Периодически обнаруживаю в интерактивных веб-интерфейсах разных порталов (магазины, банки, госконторы и т.п.) различные глюки поведения. Иногда это обычное искажение разметки, текста или изображений, но бывают и ошибки, характерные для неправильной работы исполняемого кода (серверного или клиентского JS). Пишу в поддержку, там первым делом советуют "почистить кэш и куки, перезапустить браузер, попробовать другой браузер". Разумеется, это никогда не помогало. Объясняю, что проявление характерно в первую очередь для ошибок в логике работы кода, или для порчи записей в БД, но там настаивают, что нужно "протереть фары, попинать колеса".

Так надо говорить, что ты это уже сделал, но не помогло.

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно? Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?

Ну например, JS может быть в нескольких файлах. Один обновился, а остальные из кэша взялись. А обновившийся рассчитывает, что остальные тоже последней версии.

Здравствуйте, vsb, Вы писали:

vsb>Ты что-то путаешь. Если не указывается длина, используется chunked encoding. У каждого куска указывается длина отдельно и в конце кусок нулевой длины, как маркер конца. Полагать неполный файл валидным невозможно.
Да, современные фреймворки стараются делать именно так, и принимают меры, чтобы не дать программисту напороть. Тем не менее, возможность напороть при ручной реализации всё ещё есть даже сейчас, хотя для этого требуется меньше усилий.
А ситуации, когда у меня реально в кэше лежат недогруженные данные, я встречал ещё не так давно.
vsb>Согласен, всё так. Главное не забыть про это, когда один ресурс ссылается на другой (например css import). А в идеале это всё должен делать фреймворк. Тогда вместо версии ресурса можно добавлять его хеш-сумму.
Да, в том же ASP.NET для этого есть специальные механизмы.

Здравствуйте, okon, Вы писали:

O>могут в куках могут быть данные которые не работают с новой логикой.

Что значит "данные не работают с новой логикой"? Мне всегда казалось, что это логика (алгоритм) работает с данными. А если вдруг поменяли формат кук, то алгоритм должен позаботиться и об их перезаписи.

Здравствуйте, Sinclair, Вы писали:

S>Классический сценарий: сервер отдаёт CSS или JS динамически — генерирует на лету.

Генерация JS на лету настолько популярна? А смысл? Это реальная необходимость, или больше выпендреж?

S>Стили не применяются, JS пытается вызвать функции, которых нет.

Когда не применяются стили — съезжает разметка, тут все понятно. А при вызове отсутствующих функций в JS браузер разве не должен вываливать ошибку?

Здравствуйте, Ops, Вы писали:

Ops>Есть один довольно серьезный сервис, которым пользуюсь, так он мне периодически выдает белую страницу, пока не почищу данные

В таких случаях у меня самого возникает подозрение прежде всего на браузер/кэш. А вот когда все отображается правильно, но скрипт, например, требует что-то подтвердить, или утверждает, что в каком-то поле ошибка, когда ее там нет — подозрение возникает прежде всего на скрипт.

Здравствуйте, Pzz, Вы писали:

Pzz>Ну например, JS может быть в нескольких файлах. Один обновился, а остальные из кэша взялись. А обновившийся рассчитывает, что остальные тоже последней версии.

А кто должен обеспечивать целостность такого набора скриптов — браузер, или таки разработчик?

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Генерация JS на лету настолько популярна? А смысл? Это реальная необходимость, или больше выпендреж?
Понемножку всего. Иногда возникают высокие идеи при низкой квалификации. Типа "а давайте соберём все скрипты в один файл и минифицируем". В последнее время это происходит пореже, т.к. существуют десятки фреймворков, которые уже делают именно это, только как следует.

S>>Стили не применяются, JS пытается вызвать функции, которых нет.
ЕМ>Когда не применяются стили — съезжает разметка, тут все понятно. А при вызове отсутствующих функций в JS браузер разве не должен вываливать ошибку?
Он и вываливает. Можно открыть консоль и насладиться.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>В таких случаях у меня самого возникает подозрение прежде всего на браузер/кэш. А вот когда все отображается правильно, но скрипт, например, требует что-то подтвердить, или утверждает, что в каком-то поле ошибка, когда ее там нет — подозрение возникает прежде всего на скрипт.

А при чем тут кеш/браузер? Это как раз скрипт не может корректно обработать сохраненное им же (или его предыдущей версией) состояние, и падает до отрисовки.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Генерация JS на лету настолько популярна? А смысл? Это реальная необходимость, или больше выпендреж?

Это, например, простой способ передать данные статическому скрипту на странице. Подгружаем динамически созданный скрипт, который заполняет нужные переменные. Альтернативы есть, конечно, но так иногда удобнее.

Здравствуйте, Sinclair, Вы писали:

ЕМ>>А при вызове отсутствующих функций в JS браузер разве не должен вываливать ошибку?

S>Он и вываливает. Можно открыть консоль и насладиться.

Кстати, по какой причине в браузерах упорно сохраняется тенденция скрывать ошибки JS от пользователя, показывая их лишь в консоли? Ладно, когда в начале 2000-х JS применялся в основном для украшательства, и глюки обычно только портили разметку, но ведь давно уже на JS много где завязана вся логика работы.

Помнится, IE когда-то вываливал сообщения об ошибках в JS-коде, но затем это изжили. А в десятках изжили сообщения об аварийном завершении процесса

Автор: Евгений Музыченко
Дата: 20.09.19

.

Здравствуйте, Ops, Вы писали:

Ops>А при чем тут кеш/браузер? Это как раз скрипт не может корректно обработать сохраненное им же (или его предыдущей версией) состояние, и падает до отрисовки.

Дык, а я о чем? Когда в глюке четко видны уши кривого скрипта, но поддержка настаивает на очистке кэша и удалении кук — это признак еще и кривой поддержки.

Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кстати, по какой причине в браузерах упорно сохраняется тенденция скрывать ошибки JS от пользователя, показывая их лишь в консоли? Ладно, когда в начале 2000-х JS применялся в основном для украшательства, и глюки обычно только портили разметку, но ведь давно уже на JS много где завязана вся логика работы.
По прагматической.
Дело даже не в том, что большинство ошибок критическими не являются — ну, подумаешь, анимация менюшечки не сработала.
А в том, что пользователь всё равно ничего не может сделать. Все алерты должны быть actionable. А тут — ну, покажете вы пользователю "ойойой, тут вызвали несуществующую функцию". Дальше что? Какие варианты будут у пользователя? Развернуться и уйти (и его супердешёвый авиабилет, который он тут два часа накликивал себе в авиасейлсе, уйдёт другому), или продолжать?
Ну, так развернуться и уйти он может и сам, без помощи модального диалога. А продолжать мы можем и без того, чтобы поминутно спрашивать "папа, я поскользнулся, мне вставать и идти дальше?".

ЕМ>Дык, а я о чем? Когда в глюке четко видны уши кривого скрипта, но поддержка настаивает на очистке кэша и удалении кук — это признак еще и кривой поддержки.
Основная роль поддержки — держать людей подальше от разработчиков.

Здравствуйте, Sinclair, Вы писали:

S>Дело даже не в том, что большинство ошибок критическими не являются — ну, подумаешь, анимация менюшечки не сработала.

А как браузер поймет, какие ошибки являются критическими? Почему бы тогда не внедрить тот же подход в традиционном софте, и молча глотать исключения вместо того, чтобы вываливать сообщения или тупо прибивать приложение?

S>А в том, что пользователь всё равно ничего не может сделать.

Пользователь, которому ежеминутно вываливатся сообщения об ошибках, может пожаловаться администрации сайта, а может тупо уйти с него. Хоть какая-то обратная связь. Зато говнокода будет поменьше.

S>Ну, так развернуться и уйти он может и сам, без помощи модального диалога.

Только потратит большее количество времени на понимание того, что сайт делали криворукие разработчики.

Здравствуйте, Sinclair, Вы писали:

S>Основная роль поддержки — держать людей подальше от разработчиков.

Да, со временем такой подход становится основным.

Здравствуйте, Sinclair, Вы писали:

S>По прагматической.
S>Дело даже не в том, что большинство ошибок критическими не являются — ну, подумаешь, анимация менюшечки не сработала.
S>А в том, что пользователь всё равно ничего не может сделать. Все алерты должны быть actionable. А тут — ну, покажете вы пользователю "ойойой, тут вызвали несуществующую функцию". Дальше что? Какие варианты будут у пользователя? Развернуться и уйти (и его супердешёвый авиабилет, который он тут два часа накликивал себе в авиасейлсе, уйдёт другому), или продолжать?
S>Ну, так развернуться и уйти он может и сам, без помощи модального диалога. А продолжать мы можем и без того, чтобы поминутно спрашивать "папа, я поскользнулся, мне вставать и идти дальше?".

Гладко было на бумаге. А по факту, сейчас любят паковать скрипты всякими вебпаками, делая из 100 файлов 1, и когда вылетает исключение из-за анимации менюшечки, скрипт дальше не отрабатывает, а так как файл один на кучу функций, важные тоже отваливаются.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А как браузер поймет, какие ошибки являются критическими?
Никак. Либо мы все считаем критическими, либо все — нет.
Почему бы тогда не внедрить тот же подход в традиционном софте, и молча глотать исключения вместо того, чтобы вываливать сообщения или тупо прибивать приложение?
ЕМ>А почему вы думаете, что это ещё не так?

S>>А в том, что пользователь всё равно ничего не может сделать.
ЕМ>Пользователь, которому ежеминутно вываливатся сообщения об ошибках, может пожаловаться администрации сайта, а может тупо уйти с него. Хоть какая-то обратная связь. Зато говнокода будет поменьше.
Эмм, а вам что, не очевидно, что пользователь скорее просто перейдёт на браузер, который не вываливает на его любимых сайтах алерты каждые 30 секунд?
ЕМ>Только потратит большее количество времени на понимание того, что сайт делали криворукие разработчики.
Вот именно. Так что текущая схема удобна и авторам веб сайтов и производителям браузеров.

Здравствуйте, Sinclair, Вы писали:

S>Либо мы все считаем критическими, либо все — нет.

Почему? Навесить на каждый скрипт атрибут, по умолчанию — выкидывать окно. Параллельно в поисковики добавить фактор ранжирования по количеству скриптов, для которых задан атрибут "игнорировать ошибки". И нехай страницы с кривыми скриптами болтаются где-нибудь внизу, где им и место.

ЕМ>>Почему бы тогда не внедрить тот же подход в традиционном софте, и молча глотать исключения вместо того, чтобы вываливать сообщения или тупо прибивать приложение?
S>А почему вы думаете, что это ещё не так?

Какие ОС молча глотают необработанные исключения нативных приложений?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Почему? Навесить на каждый скрипт атрибут, по умолчанию — выкидывать окно. Параллельно в поисковики добавить фактор ранжирования по количеству скриптов, для которых задан атрибут "игнорировать ошибки". И нехай страницы с кривыми скриптами болтаются где-нибудь внизу, где им и место.
Всё бы хорошо, но эта идея требует скоординированной работы сразу трёх групп несвязанных между собой людей:
1. Разработчики браузеров должны изобрести атрибут для скриптов (кстати, как его сделать? будет ли он частью JS, или частью HTML разметки, или заголовком HTTP).
2. Разработчики сайтов должны внезапно осознать наличие этого атрибута, и правильно его применить на своих сайтах
3. Разработчики поисковиков должны зачем-то начать ранжировать сайты в соответствии с этим новым атрибутом.

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

Это выглядит как рецепт для неудачи.

ЕМ>Какие ОС молча глотают необработанные исключения нативных приложений?
ОС — никакие. А приложений, которые молча глотают исключения — вагон и маленькая тележка. Скорее наоборот — софта, который смог корректно обработать проблему, которая возникла в фоновом потоке, меньшинство.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного?

Вот конкретно сейчас такая же хрень с PayPal. Где-то неделю назад легко и успешно сделал donate для RSDN, заплатив с баланса (у меня нет привязанных к счету карт). Примерно в то же время попытался заплатить за Browsec VPN — PayPal безальтернативно требует привязать карту, платить с баланса не дает.

Написал в поддержку — оттуда сперва пришла пара автоматических ответов с предложением отключить VPN (это они явно среагировали на контекст сообщения, где я упоминал Browsec VPN) и попробовать другой браузер. Я даже в страшном сне не могу предположить, насколько кривым должен быть серверный код, чтобы так себя вести из-за VPN или неподходящего браузера, однако попробовал в Chrome — разумеется, с тем же результатом. Теперь мы с PayPal уже на протяжении недели обмениваемся сообщениями, в которых они уверяют, что проблема уже должна исчезнуть, а если возникнет снова, то мне нужно начать с чистки кэша и кук. Я, со своей стороны, шлю им однотипные скриншоты, и требую включить мозги.

Во всем этом есть явная странность: если бы все эти службы поддержки хотели любой ценой отделаться от пользователей с проблемами, им следовало бы добавить к предложениям сменить браузер, очистить кэш и удалить куки, предложения о перезагрузке/переустановке системы, переустановке браузера, смене интернет-подключения и т.п. Формальных отписок можно придумать достаточно. Но почему-то они все напирают именно на кэш и куки. Получается, что это таки помогает в изрядном большинстве случаев? Но это ведь означает, что код на большинстве сайтов не просто плох, а реально ужасен?

Здравствуйте, Евгений Музыченко, Вы писали:

Чё только не бывает! Вот из личного опыта:
1. Ест SPA приложение на React, которое цепляется к бекенду.
2. Для запуска приложения в отладке, поднимается node.js на 3000 порту и все запросы к апи перенаправляет на реальный бекенд.

В какой-то момент в консоль начало сыпать ошибками об обращении к беку. Что только не пробовал, всё починилось реально сбросом кеша браузера — хотя казалось бы — обращение к беку идёт только через нодовский прокси и если в консоли браузера появляется ошибка, то это явно прокси что-то не то делает. Но нет