Периодически обнаруживаю в интерактивных веб-интерфейсах разных порталов (магазины, банки, госконторы и т.п.) различные глюки поведения. Иногда это обычное искажение разметки, текста или изображений, но бывают и ошибки, характерные для неправильной работы исполняемого кода (серверного или клиентского 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>Ну, так развернуться и уйти он может и сам, без помощи модального диалога.

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