Если вы начинающий веб-разработчик — добро пожаловать под кат, Senior-ы вряд ли найдут там для себя что-то новое
1. Сбрасывайте кеши статических файлов
Очевидная вещь, однако с данной проблемой часто стыкаются начинающие разработчики. Далеко не все используют продвинутые системы сборки и деплоя frontend-а, а поэтому много где работает старый добрый подход вроде
<script src="/script.js"></script>
<link href="/style.css" rel="stylesheet" type="text/css" />
Нет, в этом нет ничего плохого, всё работает и будет работать. Проблема же возникает при изменении этих файлов. Разработчик делает изменения, заливает на прод, отписывает заказчику. Заказчик проверяет — и говорит что у него ничего не работает. А всё почему — потому что его браузер держит в кеше старую версию файлов. И у всех остальных пользователей — то же самое. Банально? Конечно! Но наступают на эти грабли очень часто. Решение простое — добавлять случайный GET параметр. Например:
<script src="/script.js?v=%текущая дата%"></script>
// вместо
<script src="/script.js"></script>
перед каждым коммитом изменённого файла. Веб-сервер просто проигнорирует этот параметр, а вот браузер потянет файл заново, потому что url изменился.
2. Не храните важные файлы в публичной директории
Распространённая схема: «сделаю code.backup.zip в корне, выкачаю, и удалю. Я же быстро, кто там знает что есть такой файл». Проблема же заключается в том, что практически все сайты время от времени сканируют боты, которые тупо перебирают очевидные ссылки вроде /update.sql, /backup.sql, /config.php.bk, итд. Вариантов в их базе — сотни. Поэтому такое оставление файлов «по-быстрому» в открытом доступе может легко выйти боком. А оставлять их на постоянной основе — так точно вылезет.
Если уж очень припекло — создавайте файлы с абсолютно случайными именами. Но лучше вообще так не делать. Не стоит быть неуловимым Джо.
3. Development и Production сайты — это всегда разные серверы
Подход при котором на одном сервере крутится и production и development сервер тоже часто встречается. Иногда, при особой упоротости, совпадают даже ключи поключения к БД (которые тоже на одном сервере), и отличаются только название баз. Чем чревато:
- банально перепутать, и натворить делов на «боевой» системе. Не тешьте себя иллюзиями «да я всегда очень внимателен»
- случайно положить прод. Делал эксперименты на дев-сайте, что-то пошло не так, выжрало все ресурсы/положило БД — ОП, и у вас заодно прилёг основной сайт
- получить проблемы при обновлении версии софта на сервере. Решили перевести проект с php5.6 на 7.2? А оба сайта крутятся на одном сервере, и сделать разные версии для разных доменов — та ещё боль. Не заливать же сразу в прод, верно? Вот и возникла проблема с тестовым сайтом.
В общем, правило простое — production сайт (и его БД) — это всегда отдельный сервер.
4. Сверяйте локальные конфиги и конфиги сервера
В крупных проектах, где есть отдельный шаман админ, docker (или vagrant), много серверов, балансер итд — эта проблема, конечно же, не возникнет. Накатил образ окружения — и погнал. Однако посмотрим правде в глаза — много где до сих пор используют подход «обновил файл — залил через FTP», и получить такой проект начинающему разработчику — как раз плюнуть. И вот тогда возникают проблемы, когда локально всё работало, а на проде — отпало. Поэтому всегда сверяйте идентичность окружений. Иногда минорная версия какого-нибудь софта (вроде php 7.0 на проде и 7.2 локально) может всё круто сломать.
5. Логируйте сложные операции как можно тщательнее
Молодые (не в плане возраста — а в плане опыта) разработчики часто забывают о логах, надеясь на то что это сделает фреймворк или же веб-сервер. Так то оно так, но такие логи помогут поймать только очень грубые ошибки, вроде ошибок синтаксиса или неправильного запроса. Поэтому при разработке сложного функционала всегда пишите в логи всё что можете, это значительно облегчит жизнь в будущем. Вы же не пишете highload проект вроде конкурента Facebook, где стоит беспокоиться о потери лишней миллисекунды на запись в лог, не так ли?
6. Проверьте всё ли вы храните в системе контроля версий
Все начинающие девелоперы знают что весь код нужно хранить в системе контроля версий вроде GIT или SVN. Но при этом часто забывают о других вещах которые тоже следовало бы бекапить:
- crontab. Представьте ситуацию — на проекте 20 cron-задач, и, вдруг, что-то случилось с сервером. Код и база данных у нас в бекапах, мы же молодцы. А вот на какое время стоял какой крон — придётся вспоминать, потому что это мы нигде отдельно не хранили
- настройки веб-сервера отличные от умолчания. Если для работы веб-сервера необходимы какие-то специальные настройки — обязательно надо где-то хранить эту информацию, иначе при следующем переезде/перенастройке/смене разработчика будет снова потрачена куча времени
- бинарные зависимости которые надо ставить руками. Часто встречается следующее: проект использует, например, memcached — но об этом нигде не написано. Следующий разработчик обязательно будет в восторге при поиске всего необходимого для запуска. Конечно, сами бинарники пихать в GIT не надо, но оставить файлик вроде README — будет замечательно.
7. Не используйте продукты вроде phpMyAdmin на постоянной основе
Вот это вообще популярный момент. Особенно на shared-хостингах. Чем это плохо: проблемы безопасности (вы уверенны что завтра не найдут уязвимости в таком продукте?), проблемы надёжности (упал веб-сервер — к базе не достучаться), проблемы удобства (нужно скормить большой бекап? Это надолго. Плюс конфиги веб-сервера надо править). Решение — используйте прямое подключение к БД, желательно через SSH-тоннель, не оставляя открытый порт напрямую.
Кстати, это пересекается с пунктом номер 2 — открытый phpMyAdmin боты ищут в первую очередь (сразу после wp-admin.php)
8. Не удаляйте ничего как можно дольше
Это так называемый подход soft-delete. У вас есть хорошая система, в которой пользователь может загружать файлы, а может удалять. Перед удалением у вас стоит три вопроса в стиле «А вы точно хотите удалить файл?» Вы точно уверенны что пользователь ну никак не сможет удалить что-то случайно. Поверьте — сможет. Поэтому, если у вас не конкурент facebook, и вам не надо работать с терабайтами файлов/cообщений — не удаляйте ничего лишний раз. Рано или поздно это пригодится.
9. Не верьте своим глазам
Иногда бывают случаи которые полностью выбивают из колеи. Явно видишь что-то одно — а код говорит о обратном. Видишь при выводе 4 символа — а код считает их как 9. Вина этому — невидимые символы. Особенно критично при работе с какими-нибудь PDF-файлами или чем-то вроде того, когда на вид всё хорошо — а парсер ругается. Ну или же коллеги пошутили, и подкинули невидимый символ в код, пока вы отошли на обед приятного дебага! Так же могут быть подобные проблемы с многобайтовыми кодировками.
Решение — да его нет как такового, следует просто знать о возможности, и это уже сэкономит вам много времени в подобной ситуации.
10. Пишите код вежливо
И напоследок немного забавный совет. Не используйте для дебага то что не стоит показывать клиенту. Иногда ну очень хочется задебажить код чем-то вроде
if(everythingIsBad()){
die('FUCK');
}
Но, аналогично совету номер 3 — не тешьте себя иллюзиями «я никогда не забуду убрать дебаг код». Иначе когда такое вылезет на production-сайте — будет очень неловко объяснять что это и почему оно красуется на главной странице.
В своё время эти советы сэкономили бы мне кучу времени и сил. Надеюсь кто-то найдёт их полезными и для себя, а ещё лучше — дополнит их в комментариях.
Комментарии (72)
Melkij
23.05.2018 16:37Иногда минорная версия какого-нибудь софта (вроде php 7.0 на проде и 7.2 локально)
Это очень даже major версия. И совершенно легально поведение может быть изменено. Вот в действительно минорных релизах (это 7.0.х, 7.2.х и т.д.) — редкость.
А вообще совет — поинтересуйтесь политикой нумерования используемого у вас ПО. Бывают интересные фокусы, вроде mysql, где первый стабильный релиз 8.0 ветки — это внезапно 8.0.11. А более ожидаемый 8.0.0 — это dev версия. Аналогично первый стабильный 5.7 был за номером 5.7.9. Сообщество PHP же отдельно выделяет 7.2rc, 7.2beta, а 7.2.0 — готовый первый релиз.SirEdvin
23.05.2018 17:27+2Вообще-то, согласно нормальной semver терминологии — вторая цифра это минор, а третья — патч.
youngmysteriouslight
23.05.2018 17:34+1Насколько я понял, смысл комментария был в том, что если софт не использует semver, рассчитывать на поведение в соответствии с семверной терминологией не стоит.
В т.ч. вторая цифра может указывать обратнонесовместимые мажорные изменения.
Melkij
23.05.2018 17:38Вот поэтому и совет поинтересоваться политикой нумерации каждого используемого ПО.
Для php актуально по-прежнему, mysql до 8.0, postgresql до 10.0, да и ядра linux до 3.0 тоже — major версия нумеруется первыми двумя цифрами, minor — третья. Так переход php 7.1 к 7.2 — major change, включая incompatible API change.
Akdmeh
23.05.2018 17:07+411. Изучайте систему, на которой работают серверы. Вы должны понимать Linux. Если работаете с PHP — должны понимать, что делает nginx, php-fpm, почему в 2k18 можно жить без Apache
12. Читайте ru.highload
13. Если PHP — читайте как Библию «PHP: The Right way»
14. Изучите, что такое тестирование и начинайте его применять как можно скорее. В частности, обратите внимание на Codeception
15. Прежде чем написать любую библиотеку — потратьте несколько минут и изучите, не существует ли уже такой (немаловажно, проверьте, чтобы она поддерживалась и развивалась). Библиотеки обычно написаны с учетом многих багов серверов, браузеров, устройств и позволят вам не натыкаться на них самостоятельно.
16. Нет. Ваш собственный фреймворк не будет работать лучше и быстрее. Изучите существующий фреймворк, а лучше два-три. То время, которое вы потратите на поддержку и переписывание своего фреймворка в новых условиях и на написание библиотек под него — можно потратить на написание реальных проектов.
17. Пишите без ошибок. Ваш код не должен выбрасывать ни малейших notice, если они возникают — учитесь их сразу же устранять.
18. Работа с сайтом через браузер — не единственный канал общения с приложением. Изучите, как запускать приложения в консоле и какие преимущества это вам предоставляет.
wirtwelt
23.05.2018 17:26+1Супер! Сразу два совета прям в руку ) Категорически благодарен и желаю вам всяческих успехов, здоровья и хорошего настроения
Разрешите вопрос от новичка с восьмилетним стажем колхозного веба )Извиняюсь, долгое время беспокоит как раз решение по совету 3, то есть развертывание обновлений и окружения. В интернете много информации, всякие докеры и прочее. По факту все выглядит для меня слишком страшным и новомодным, временами ненадежным.
Если не трудно, посоветуйте, что почитать или куда посмотреть по развертыванию обновлений, при условии двух задач: 1) что-то быстро вот прям сейчас поправить, вроде опечаток, кнопок или оформления страниц и 2) залить большую страшную фичу/раздел сайта, со своим кодом и таблицами в БД.
Сейчас просто «git push» и «git pull» на master. Это еще терпимо, но с базой все очень плохо — ручное обновление, создать таблицу, поправить ключи, прописать индексы. Жуть. Не научно, криво, косо, бесит, но как лучше сделать — все руки не доходят найти и прочитать, и главное — внедрить в уже работающие на старой схеме проекты, не поломав ничегоzharikovpro
23.05.2018 18:00+1Про базу посмотрите словосочетание «database migrations tool». Вот пример инструмента. Если используете популярные фреймворки типа Laravel, в них работа с миграциями БД уже встроена, смотрите доки.
wirtwelt
23.05.2018 19:05Спасибо, посмотрю. Интереснее не база, а чтоб прям целиком, код и база, поэтому упомянул docker, но как им практически пользоваться для этой цели я пока не понял
zharikovpro
23.05.2018 19:33Это очень общий вопрос. В чем конкретно трудность? Накатили код, провели миграцию. Или провели миграцию, накатили код. Выбирайте любой порядок. Бывает правда что для некоторых случаев нужно писать код, который умеет работать (хотя бы временно) со старой и новой версией базы на момент переключения. Но это отдельная история, все сильно зависит от ваших задач.
IgorSaf
24.05.2018 11:08Делаю следующим образом — миграции для БД используются встроенные во фреймворк, хранятся вместе со всем остальным кодом в репо. Сразу после git pull на сервер делается что-то в духе php index.php migrate (накатывается миграция). Таким образом и код, и БД поддерживаются актуальными в две строки в консоли
vlreshet Автор
23.05.2018 18:55Пожалуйста, рад что пригодилось! :) А какие советы «прям в руку»?)
wirtwelt
23.05.2018 19:121 — буквально на прошлой неделе был косяк с кешированным JS, кнопочки у клиента не нажимались, я знал про прием, но не использовал
3 — обсуждали повышение мощности сервера, но develop и production лежат на одной машине, и базы просто названием отличаются, ваш совет очень кстати получился
7 — спустя полгода после старта проекта до сих пор в корне лежит myadmin )) под Basic Auth, но тем не менее
Отчасти еще 8, но тут много спорных моментов, удалить vs скрыть, спорить не берусь, согласен на 80% что в подавляющем большинстве случаев выгоднее скрыть, не удаляя безвозвратно данные
batment
23.05.2018 17:33+1В общем, правило простое — production сайт (и его БД) — это всегда отдельный сервер.
Мало того, даже с разными серверами на разных URL можно подумать, что находишься в админке на стейджинге, и сделать что-то плохое. Такую проблему проще всего решить какой-нибудь явной меткой, например плашкой DEV / PROD где-нибудь на видном месте.vlreshet Автор
23.05.2018 20:34Лично я себе в stylish прописал правило для продакнш-адреса. На нём всё дико красное, и не заметить это не возможно.
Samouvazhektra
23.05.2018 18:23Все начинающие девелоперы знают что весь код нужно хранить в системе контроля версий вроде GIT или SVN
Но при этом важно не палить токены/пароли
vlreshet Автор
23.05.2018 18:56+2А тут простое правило — конфиг никогда не коммитится. Можно хранить примеры конфигов в гите, но сами конфиги — нет.
Softer
23.05.2018 21:20Коммит конфига — не самое страшное…
А вот когда «разработчик» пишет В КОНФИГЕ что-то вроде
if ($server_hostname == "MyLovelyTest") { // Тут настройки } elseif ($server_ip == "127.0.0.1") { // Тут настройки локалхоста } else { // Настройки прода }
причем все в гите, с захардкожеными путями (и доменами) и в файле с названием вроде ClassLoader.php… Убивать хочется просто от воспоминания…vlreshet Автор
23.05.2018 22:21Ууух, круто будет запустить это на локальной машине ($server_hostname != «MyLovelyTest»), да на правильно настроенной виртуально машине ($server_ip != «127.0.0.1»).
Жесть конечно, не поспорить.
YemSalat
24.05.2018 13:04Альтернативный вариант — использовать в конфиге ENV переменные.
(Упс, не обновил страницу — опередили :)
artemt
23.05.2018 21:31+5Development и Production сайты — это всегда разные серверы
Давным давно, в незапамятные времена устроился я в некую контору, разрабатывающую сайт по заказу авиабилетов. Вышел в первый день на работу. Сразу задание — поправить хранимку в базе.
— Разработка у нас ведётся на продакшн базе данных, — сразу огорошил тимлид.
— Так как же работать? — удивился я.
— Аккуратно. Всё-таки, там люди билеты заказывают…
Тут я испугался.
Через месяц я ошибся. Передал не тот параметр в html форме и вместо редактирования организации проскочило удаление. Пошёл глянуть в базу и захолодело. На таблице организаций стояло каскадное удаление сотрудников. А на таблице сотрудников каскадное удаление авиабилетов. Сразу обратился к тимлиду.
— Ерунда, — ответил он — Эта организация фейковая, для опытов.
Потом подумал и глубокомысленно произнёс — Надо бы бэкап базы сделать.
— А когда последний раз делали? — наивно спросил я.
— Полтора месяца назад…
Вот здесь мне по настоящему стало страшно.
Как-то подвис рабочий комп. Я кнопку жёсткой перезагрузки нажал, а на мониторе ничего не происходит. Нажал ещё раз. Смотрю, что-то народ суетится.
— Что такое? — спрашиваю.
— Продакшн сервер упал! — отвечают.
— А где он?
— Да вот же, слева от твоих ног.
— А где мой рабочий комп?
— Справа от твоих ног...
Два месяца там проработал. Стивена Кинга с тех пор без улыбки читать не могу.
vlreshet Автор
23.05.2018 22:24А вы не интересовались, в чём была мотивация такого странного подхода?)) Не то чтобы этому могло быть хоть какое-то адекватное оправдание — тут просто интересно. Ладно бекапы не делают, ладно сервер под ногами стоит… но поднять тестовую базу — это же раз плюнуть…
artemt
23.05.2018 23:01Нет, не спросил. Сразу ошалел, что в первый же день на продакшн отправили. А потом сработал эффект "здесь так заведено".
А "заведено" было странно. Нельзя читать новости на рабочем месте. Пусть так. Но мне сделали замечание, что я MSDN читаю...
artemt
24.05.2018 10:31Кстати, вспомнил случай с другой работы, который может подсказать причину беспредела с разработкой на продакшн базе.
Нужно было поднять бэкап базы для правки легаси проекта. Я автоматически назвал базу ХХХ_dev. И тут прилетел привет от бывшего коллеги. Он где-то в коде использовал имя базы и она должна называться именно ХХХ, Sic! Так как там production и developer сервера различались, то я просто плюнул и назвал ХХХ.
springimport
23.05.2018 22:27Хорошо быть новичком :)
Вот бы такие понятные и определенные советы для сложных вещей, а то как посмотришь — у той технологии такие минусы, у той — другие и во весь рост встает выбор из меньших зол.
f0rk
23.05.2018 22:58Мне вот интересно, любители добавлять таймстампы в урлы считают, что разработчики браузеров придумали кеширование чисто из вредности?
Для справки, в девтулзах в хроме есть галочка "disable cache".
vlreshet Автор
23.05.2018 23:10А всех пользователей вы тоже попросите эту галочку поставить?
А вообще вы, видимо, не уловили суть. Таймштамп ставится один раз — при изменении файла. То есть кеш сбрасывается только один раз. Так что разработчики браузеров не зря старались кеш продолжает работать. А таймштамп в ссылке — всего-лишь способ инвалидировать (обновить) кеш.f0rk
23.05.2018 23:50А всех пользователей вы тоже попросите эту галочку поставить?
У них пусть по ttl инвалидируется, в большинстве ситуаций — это ок.
Таймштамп ставится один раз — при изменении файла.
Да, наверное прочел невнимательно, но я бы ограничился только выкаткой критичных фиксов таким образом.
Меня просто что-то стригерило, наверное потому что много раз видел именно в шаблонах фигню типа
"script.js?" + now()vlreshet Автор
24.05.2018 00:11«script.js?» + now() — ну это дичь, само собой. Об этом речи не идёт
критичных фиксов таким образом.
Ну, мне кажется редко бывают случаи некритических изменений. Если это багфикс (любой) — его нужно распространить как можно быстрее всем. Если это новая фича — под неё уже наверняка написан html, так что нужно выкатить тоже оперативно. Разве какой-нибудь лёгкий редизайн, или вроде того… Но, опять таки, если у нас не проект на миллион пользователей в день (которые могут и сервер положить, если все одновременно пойдут свежий скрипт тянуть) — то я бы обновлял таким путём все изменения. Другое дело что если из 10 скриптов на проекте обновили только один — то, наверное, нет смысла обновлять кеш и остальным (в случае глобального таймштампа на всю статику в проекте).f0rk
24.05.2018 00:28могут и сервер положить
на больших проектах скрипты в cdn лежат, но уменьшать счета за трафик — безусловно благое дело :)
neurocore
24.05.2018 06:16«9. Не верьте своим глазам» — вообще универсальное правило для любого программиста. Наши органы восприятия неидеальны и нужно принимать это как данность. Поэтому всегда нужно перепроверять свой код различными способами: отладка, тесты, подсадить коллегу с вопросом «что здесь написано?»
qrck13
24.05.2018 08:36Вместо «FUCK» отлично подойдет что-то маскирующее вроде «REMY SPEAK» (https://www.youtube.com/watch?v=NVOL3tMDzEs)
Bloodshark
24.05.2018 10:58Ещё совет: изучите как работает linter.
А встроенный линтинг в редакторе сэкономит кучу времени, де-факто подсказав о незакрытой скобке или другой случайной опечатке.
tinoajato
24.05.2018 10:583. Development и Production сайты — это всегда разные серверы
Да. Работало так год на одном серваке, пока не уговорил начальника сделать по нормальному. Буквально через месяц случайно сломал dev, хотя был очень аккуратен. Бэкапы делаются, вроде не страшно, но нервы сильно потрепало бы восстановление…
Raftko
24.05.2018 15:48+1Восьмой совет «Не удаляйте ничего» может быть неправильно истолкован. Не превращайте проект в помойку. Всякие index.php1,index.php2,index.phpBK,__index.php и прочие старые версии файлов, для них есть системы контроля версий. Закомментированные куски «авось пригодится» туда же. Старые классы, функции, которые «да это старая реализация, сейчас уже новые функции везде используются». Всё удалять. Только перед этим убедитесь, что действительно нигде не осталось старой зависимости:)
zzzmmtt
25.05.2018 07:58Насколько я понял автора, речь не о коде, речь о пользовательских файлах (аватары, документы, музыка, etc).
t_kanstantsin
25.05.2018 08:43Имеются в виду пользовательски данные и файлы.
Например, загрузил свой файл с отчётом, а через месяц решил удалить. А ещё через неделю понял, что других копий отчёта не существует.
Или удаляется товар/заказ/что угодно из бд — никогда не знаешь, понадобится ли это потом восстановить.
Softer
1. Для себя с делал такую схему (прошу помидорами не кидаться, это pet-ptoject :) ):
* В движке (в моем случае — PhalconPHP) есть метод который отдает случайное число (генерит новое, сохраняя его в memcached, или сразу достает оттуда если оно уже сохранено).
* В шаблонах прописано что-то вроде
* В админке есть кнопка «Сброс статик-кеша» которая банально киляет элемент из мемкеша. Причем даже к CI прикрутить не сложно.
работает уже года 4, если не 5 сбрасывая как кеш браузера так и кеш nginx-а на фронте.
vlreshet Автор
ИМХО — нормальное решение, я бы помидором не кинул)
надо и себе такое к laravel прикрутить
Softer
Ну мало ли — щас набегут любители «продвинутых систем сборки и деплоя frontend-а»… :)
vlreshet Автор
Cо словами «а наааам в webpack-е для такого надо всего-лишь поставить три плагина и написать небольшой конфиг!» :D
Шутки шутками, а не стрелять из пушки по воробьям не люблю) У самого проект на самом новом laravel — но статика работает «по-классике», без изворотов.
SerafimArts
В Laravel это идёт из коробки. Достаточно просто создавать json файлик манифеста или воспользоваться их mix'ом, который сам его генерирует.
kinjalik
Для генерации рандомного числа в webpack даже плагины не нужны — можно в выходной файл встроить хэш этого файла — scripts.[hash].js
Fesor
Есть масса людей которые деплоят проекты по классике, через git, без изворотов.
NickyX3
Есть масса людей, которые кодят на боевом сервере поверх ssh, что вообще еще более по-классике и олдскульно
vlreshet Автор
По-классике и олдскульно это не поверх ssh, а через FTP (именно FTP, не SFTP), в блокноте.
kalininmr
ну… есть решения покрасивше.
я для шаблонизатора сделал тег который вставляет время изменения файла.
пишу
{% fmodts "/res/script.js?v={ts}" %} получаю /res/script.js?v=1527110460
наверное лучше было сделать фильтром
Softer
Я тоже думал про mtime, но каждый раз дергать медленный диск… (да, про дисковый кеш знаю, но все же...)
kalininmr
а он не каждый раз проверяется.
только при первой компиляции шаблона.
то есть если воркер перезапустился(кнопкой или по лимиту).
Softer
Вот. Шаблона. В моем же случае вся статика — вынесена на отдельный домен и отдельный репозиторий. Равно как и View от Phalcon'а. И для того чтобы обновить статику мне нужно обновлять шаблоны? Как-то не оптимально выходит, ИМХО…
kalininmr
они пересобираются при каждом запуске воркера.
тоесть надо перезапустить воркеры или подождать, они там периодически перезапускаются.
Fedcomp
в laravel уже проще некуда mix который идет из коробки. Но полагаю в среде php костыли изживаются годами.
polearnik
в ларавеле есть mix () Зачем вам костыли и велосипеды? а еще лучше использовать github.com/Elhebert/laravel-sri тут вам и хэши для безопасности
Graphite
Насколько я помню все современные HTTP серверы поддерживают уже много лет If-Modified-Since привязанный к mtime. Т.е. при обновлении файла на диске сервер начнет вместо 304 отдавать 200 с новой Last-Modified. Есть причина этим не пользоваться?
Почему-то именно у php разработчиков я постоянно вижу совет добавить дату или случайное число для обновления кэша на клиенте.
ellrion
Обычно на nginx ставят для статики метку кэша очень большую. И тогда на сервер даже запросы не идут.
paw-p
Причина неиспользования может быть в том, что есть еще заголовок Expires. Он указывается время, до которого контент трактуется как свежий. И только по истечении этого времени производится валидация контента заголовками If-Modified-Since или If-None-Match. Т.е. пока у вас не истекло время Expires браузер будет использовать закешированную версию и единственный метод сбросить кеш — указанный в статье, т.е. поменять сам URL.
superconductor
Есть заголовок cache-control, которым можно гибко настроить когда и зачем клиенты будут ходить на сервер. Самое тупое no-cache по действию эквивалентно совету из статьи, но лучше проставить must-revalidate и добавить etag.
vlreshet Автор
superconductor
Действительно, не внимательно прочитал и подумал, что случайное значеник предлагается добавлять на каждый хит
vlreshet Автор
Вы не один такой :) Видимо я не совсем чётко описал что имел ввиду.
AlexanderY
Лет 5 назад наткнулся на неприятный баг в Safari. Были настроены заголовки на веб-сервере. Все браузеры их учитывали, даже IE. А вот Safari игнорил — брал файлы из кэша, пока вручную его не почистишь. Поэтому пришлось использовать костыль в виде get-параметра.
ilyaplot
В таком случае изменять script.js можно с любой частотой, не задумываясь о версии. Если изменилось содержимое, измениться и хэш
sumanai
Ага, и либо перечитывание файла каждый раз при запросе, либо тот же кеш, только в другом месте.