Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 03.03.20 10:49
Оценка:
Периодически обнаруживаю в интерактивных веб-интерфейсах разных порталов (магазины, банки, госконторы и т.п.) различные глюки поведения. Иногда это обычное искажение разметки, текста или изображений, но бывают и ошибки, характерные для неправильной работы исполняемого кода (серверного или клиентского JS). Пишу в поддержку, там первым делом советуют "почистить кэш и куки, перезапустить браузер, попробовать другой браузер". Разумеется, это никогда не помогало. Объясняю, что проявление характерно в первую очередь для ошибок в логике работы кода, или для порчи записей в БД, но там настаивают, что нужно "протереть фары, попинать колеса".

Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно? Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?
код кэш куки cookies браузер browser js javascript php сервер
Re: Влияние кэша/кук браузера на работу серверного и JS-кода
От: okon  
Дата: 03.03.20 11:06
Оценка:
ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что JS-код конкретной страницы будет глючить, когда на паре десятков соседних страниц JS-код работает корректно? Или поддержка просто имеет список типовых действий, которые им предписано требовать от любого, кто жалуется на глюки?

Конечно могут в куках могут быть данные которые не работают с новой логикой.
В кэше — не знаю как он сегодня работает в брозерах, но теоретически предполагаю могут подгружаться старые картинки или даже скрипты.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.03.20 16:26
Оценка: 9 (1)
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Вот и стало интересно: могут ли ошибки выполнения кода возникать из-за каких-то особенностей кэширования страницы браузером, обработки кук и подобного? Насколько вероятно, что 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 при изменениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Ops Россия  
Дата: 03.03.20 18:41
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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

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


А это само собой, и не обязательно только предписано. "Попробуйте выключить и включить", "почистить куки" и т.п.(сброс до детерминированного состояния) устраняет обычно бОльшую часть глюков, пусть и, возможно, временно, но как раз быстрое решение техподу и нужно.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re: Влияние кэша/кук браузера на работу серверного и JS-кода
От: vsb Казахстан  
Дата: 03.03.20 20:03
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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

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


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

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

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


Это само собой. Когда к провайдеру звонишь и тебя не пускают дальше, пока не перезагрузишь компьютер.
Отредактировано 03.03.2020 20:04 vsb . Предыдущая версия .
Re[2]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: vsb Казахстан  
Дата: 03.03.20 20:09
Оценка: 76 (1)
Здравствуйте, 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). А в идеале это всё должен делать фреймворк. Тогда вместо версии ресурса можно добавлять его хеш-сумму.
Re: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Pzz Россия https://github.com/alexpevzner
Дата: 03.03.20 21:43
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


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

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


Ну например, JS может быть в нескольких файлах. Один обновился, а остальные из кэша взялись. А обновившийся рассчитывает, что остальные тоже последней версии.
Re[3]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.03.20 04:44
Оценка:
Здравствуйте, vsb, Вы писали:

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

Да, современные фреймворки стараются делать именно так, и принимают меры, чтобы не дать программисту напороть. Тем не менее, возможность напороть при ручной реализации всё ещё есть даже сейчас, хотя для этого требуется меньше усилий.
А ситуации, когда у меня реально в кэше лежат недогруженные данные, я встречал ещё не так давно.
vsb>Согласен, всё так. Главное не забыть про это, когда один ресурс ссылается на другой (например css import). А в идеале это всё должен делать фреймворк. Тогда вместо версии ресурса можно добавлять его хеш-сумму.
Да, в том же ASP.NET для этого есть специальные механизмы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 06.03.20 02:02
Оценка:
Здравствуйте, okon, Вы писали:

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


Что значит "данные не работают с новой логикой"? Мне всегда казалось, что это логика (алгоритм) работает с данными. А если вдруг поменяли формат кук, то алгоритм должен позаботиться и об их перезаписи.
Re[2]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 06.03.20 02:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


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

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


Когда не применяются стили — съезжает разметка, тут все понятно. А при вызове отсутствующих функций в JS браузер разве не должен вываливать ошибку?
Re[2]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 06.03.20 02:08
Оценка:
Здравствуйте, Ops, Вы писали:

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


В таких случаях у меня самого возникает подозрение прежде всего на браузер/кэш. А вот когда все отображается правильно, но скрипт, например, требует что-то подтвердить, или утверждает, что в каком-то поле ошибка, когда ее там нет — подозрение возникает прежде всего на скрипт.
Re[2]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 06.03.20 02:09
Оценка:
Здравствуйте, Pzz, Вы писали:

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


А кто должен обеспечивать целостность такого набора скриптов — браузер, или таки разработчик?
Re[3]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.03.20 05:01
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Генерация JS на лету настолько популярна? А смысл? Это реальная необходимость, или больше выпендреж?
Понемножку всего. Иногда возникают высокие идеи при низкой квалификации. Типа "а давайте соберём все скрипты в один файл и минифицируем". В последнее время это происходит пореже, т.к. существуют десятки фреймворков, которые уже делают именно это, только как следует.

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

ЕМ>Когда не применяются стили — съезжает разметка, тут все понятно. А при вызове отсутствующих функций в JS браузер разве не должен вываливать ошибку?
Он и вываливает. Можно открыть консоль и насладиться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Ops Россия  
Дата: 06.03.20 06:31
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


А при чем тут кеш/браузер? Это как раз скрипт не может корректно обработать сохраненное им же (или его предыдущей версией) состояние, и падает до отрисовки.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[3]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Ops Россия  
Дата: 07.03.20 13:48
Оценка:
Здравствуйте, Евгений Музыченко, Вы писали:

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


Это, например, простой способ передать данные статическому скрипту на странице. Подгружаем динамически созданный скрипт, который заполняет нужные переменные. Альтернативы есть, конечно, но так иногда удобнее.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.03.20 05:09
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


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


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

Помнится, IE когда-то вываливал сообщения об ошибках в JS-коде, но затем это изжили. А в десятках изжили сообщения об аварийном завершении процесса
Автор: Евгений Музыченко
Дата: 20.09.19
.
Re[4]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 08.03.20 05:11
Оценка:
Здравствуйте, Ops, Вы писали:

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


Дык, а я о чем? Когда в глюке четко видны уши кривого скрипта, но поддержка настаивает на очистке кэша и удалении кук — это признак еще и кривой поддержки.
Re[5]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.03.20 03:43
Оценка: 3 (1)
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Кстати, по какой причине в браузерах упорно сохраняется тенденция скрывать ошибки JS от пользователя, показывая их лишь в консоли? Ладно, когда в начале 2000-х JS применялся в основном для украшательства, и глюки обычно только портили разметку, но ведь давно уже на JS много где завязана вся логика работы.
По прагматической.
Дело даже не в том, что большинство ошибок критическими не являются — ну, подумаешь, анимация менюшечки не сработала.
А в том, что пользователь всё равно ничего не может сделать. Все алерты должны быть actionable. А тут — ну, покажете вы пользователю "ойойой, тут вызвали несуществующую функцию". Дальше что? Какие варианты будут у пользователя? Развернуться и уйти (и его супердешёвый авиабилет, который он тут два часа накликивал себе в авиасейлсе, уйдёт другому), или продолжать?
Ну, так развернуться и уйти он может и сам, без помощи модального диалога. А продолжать мы можем и без того, чтобы поминутно спрашивать "папа, я поскользнулся, мне вставать и идти дальше?".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.03.20 03:44
Оценка:
ЕМ>Дык, а я о чем? Когда в глюке четко видны уши кривого скрипта, но поддержка настаивает на очистке кэша и удалении кук — это признак еще и кривой поддержки.
Основная роль поддержки — держать людей подальше от разработчиков.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: Влияние кэша/кук браузера на работу серверного и JS-кода
От: Евгений Музыченко Франция https://software.muzychenko.net/ru
Дата: 10.03.20 08:37
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


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

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


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

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


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