![[MC-04 logo]](/mc-04/chrome/site/logo.png){kind=logo}
#1470 closed дефект (fixed)
Убрать "костыль, добавленный в r507/base и дублирующий ETag
| Reported by: | alx | Owned by: | Denis_N |
|---|---|---|---|
| Priority: | major | Component: | БД изделий АДС |
| Keywords: | Cc: |
Description
В r507/base была добавлена функция добвления ко всем ссылкам на статические файла CSS параметра v=xxxxxxxxx, формирующегося из времени модификации файла. В личной переписке разработчик пояснил, что данная мера призвана решить проблему, наблюдающуюся у пользователей, состоящую в том, что после обновления файла css на сервере браузер пользователя при загрузке страницы берет старую версию файла из своего кэша. Добавление же нового значения параметра в URI, по мнению разработчика, заставит браузер игнорировать кэшированный файл (так как URI нового файла теперь отличается от старого файла).
Насколько я понимаю, разработчик, фактически, "переизобрел" (и продублировал) ETag и связанный с ним механизм If-None-Match, который и так уже используется в системе (о существовании механизма If-None-Match разработчик не знал).
Проверка показала, что в ответ на запрос файла css сервер указывает в заголовке ответа Cache-Control: max-age:0, public. Судя по описанию этого параметра, max-age=0 предписывает браузеру всегда валидировать документ. Таким образом, во-первых, после обновления файла на сервере клиенты должны загружать новую версию файла и без каких-либо дополнительных усилий ("костылей"), а во-вторых, добавленная функция вряд ли может что-либо улучшить, так как она всего лишь дублирует уже имеющийся стандартный механизм валидации документов.
В личной переписке разработчик сообщил, что он не знает, как и почему у пользователей возникала проблема (почему браузер не загружал новую версию файла, а использовал устаревшую из кэша). Я понял так, что исследование проблемы не проводилось, причину проблемы разработчик выяснить не пытался, а просто добавил данный механизм (не зная, что аналогичный уже имеется) в надежде, что это поможет устранить проблему.
Учитывая сказанное выше, я предлагаю:
- Откатить коммит r507/base, так как он не добавляет ничего нового к уже имеющемуся стандартному механизму валидации, но, как минимум, зря загромождает код и вызывает ненужные вопросы при его чтении (как это произошло в моем случае).
- Попытаться разобраться с проблемой пользователей, а именно, выяснить, почему при загрузке страницы применяется устаревший файл стилей. Предполагалаю, что возможны самые разные причины, в том числе никак не связанные с нашей системой - ошибочная жалоба (файл загрузился новый, но пользователь ошибочно решил, что старый), "слишком агрессивное" (нарушающее стандарт, ошибочное) кэширование файла прокси-сервером, ошибочные настройки браузера, ошибка в браузере и т.п...
- После того как суть проблемы станет более-менее ясна - попытаться выработать соответствующее решение.
В свою очередь я готов оказывать помощь в меру своих сил и способностей.
Change History (2)
follow-up: 2 comment:1 by , 5 months ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
comment:2 by , 11 days ago
Replying to Denis_N:
Исправление: убран механизм версионности, чтобы посмотреть правда ли бывает, что используется кэшированные css и js у пользователей, когда есть новые.
Просматривая коммит r632/base, я обнаружил, что "механизм версионности" снова возвращен. Верно ли я понимаю, что в результате его убирания в r512/base у пользователей снова начались проблемы, связанные с использованием устаревших файлов из кэша?
Если да, была ли выяснена суть (первопричина) проблемы, или этот тикет следует переоткрыть?
In 512/base: