Как обязать браузер обновлять скрипт и файлы css при публикации моего приложения [duplicate]
Класс BitMap не был разработан для простого XML-сериализации. Итак, нет, нет простого способа исправить дизайнерское решение.
11 ответов
Параметр ?v=1.123 указывает строку запроса, и поэтому браузер будет считать, что это новый путь, скажем, ?v=1.0. Таким образом, он загружается из файла, а не из кеша. Как пожелаете.
И браузер предположит, что источник останется таким же, как только вы назовете ?v=1.123 и , если кэширует его с этой строкой. Таким образом, он будет сохранен в кэше, однако ваш сервер настроен, пока вы не перейдете на ?v=1.124 или так далее.
Это очень зависит от того, насколько вы надежны в своем кэшировании. Например, прокси-сервер squid (и, возможно, другие) по умолчанию не кэширует URL-адреса, обслуживаемые с помощью запроса, по крайней мере, это было, когда эта статья была написана. Если вы не возражаете против определенных случаев использования, которые вызывают ненужные промахи в кеше, переходите к параметрам запроса. Но очень очень легко настроить схему кэширования на основе имен файлов, которая позволяет избежать этой проблемы.
-
1Прокси-сервер squid, который был приведен в статье Steve Souders, изменил политику кэширования по умолчанию. Начиная с версии 2.7 (май 2008 г.) и версии 3.1 (март 2010 г.) поведение по умолчанию заключается в кэшировании динамического содержимого. – Josh Rack 12 June 2015 в 13:45
Другой аналогичный подход заключается в использовании htaccess mod_rewrite , чтобы игнорировать часть пути при обслуживании файлов. Ваша никогда не кэшированная индексная страница ссылается на последний путь к файлам.
С точки зрения развития это так же просто, как использование параметров для номера версии, но оно столь же устойчиво, как и имя файла.
Используйте проигнорированную часть пути для номера версии, и сервер просто игнорирует его и обслуживает незашифрованный файл.
1.2.3/css/styles.css служит для того же файла, что и css/styles.css, поскольку первый каталог разделяется и игнорируется файлом htaccess
Включая файлы версий
<?php
$version = "1.2.3";
?>
<html>
<head>
<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />
<link rel="stylesheet" type="text/css" href="<?php echo $version ?>/css/styles.css">
</head>
<body>
<script src="<?php echo $version ?>/js/main.js"></script>
</body>
</html>
Обратите внимание, что этот подход означает, что вам нужно отключить кеширование вашей индексной страницы - Использование & lt; meta & gt; теги, чтобы отключить кеширование во всех браузерах?
.htaccess file
RewriteEngine On
# if you're requesting a file that exists, do nothing
RewriteCond %{REQUEST_FILENAME} !-f
# likewise if a directory that exists, do nothing
RewriteCond %{REQUEST_FILENAME} !-d
# otherwise, rewrite foo/bar/baz to bar/baz - ignore the first directory
RewriteRule ^[^/]+/(.+)$ $1 [L]
Вы можете использовать тот же подход на любой серверной платформе, которая позволяет переписывать URL
(переписать условие, адаптированное из mod_rewrite - переписать каталог в строку запроса, кроме / #! / )
... и если вам нужно кеш-брейдинг для вашей индексной страницы / точки входа в сайт, вы всегда можете использовать gS-версию JavaSript , чтобы обновить ее.
-
1
-
2@spender Я не могу найти ссылку прямо сейчас, я боюсь, была длинная статья в блоге или SO, где Джефф Этвуд говорит об этом (IIRC) – Pekka 웃 23 May 2014 в 07:50
-
3@spender Я прочитал, что некоторые прокси-серверы (старые или могут быть настроены) игнорируют строку запроса при кешировании. – MrWhite 22 August 2014 в 13:03
-
4@spender - я слышал то же самое, и я думаю, что изменение имени файла, или путь - лучший вариант. Возможно, проще всего переместить все ваши статические файлы под именем версии, например
/static/v22/file.css, так как вы могли бы выполнять несколько файлов с переименованием одной папки, например./static/v23/file.cssи/static/v23/mystuff.js– Brad Parks 6 October 2015 в 16:18
<script type="text/javascript">
// front end cache bust
var cacheBust = ['js/StrUtil.js', 'js/protos.common.js', 'js/conf.js', 'bootstrap_ECP/js/init.js'];
for (i=0; i < cacheBust.length; i++){
var el = document.createElement('script');
el.src = cacheBust[i]+"?v=" + Math.random();
document.getElementsByTagName('head')[0].appendChild(el);
}
</script>
-
1Во время разработки / тестирования новых выпусков кеш может быть проблемой, поскольку браузер, сервер и даже иногда 3G-телефон (если вы используете мобильное развертывание) будут кэшировать статический контент (например, JS, CSS, HTML, img). Вы можете преодолеть это, добавив номер версии, случайное число или временную метку к URL-адресу, например: JSP: & lt; script src = & quot; js / excel.js? Time = & lt;% = new java.util.Date ()% & gt; & Quot; & GT; & Lt; / сценарий & GT; Если вы используете чистый HTML (вместо серверных страниц JSP, ASP, PHP), сервер вам не поможет. В браузере ссылки загружаются до запуска JS, поэтому вам нужно удалить ссылки и загрузить их с помощью JS – Conete Cristian 9 June 2016 в 01:55
-
2Я не думаю, что это будет загружать файлы JS по порядку, синхронно. – Stealth Rabbi 11 April 2018 в 19:35
Как говорили другие, переполнение кэша с параметром запроса обычно считается плохой идеей (tm) и длится долгое время. Лучше отразить версию в имени файла. Html5 Boilerplate рекомендует против , используя строку запроса, среди прочих.
Тем не менее, из рекомендаций, которые я видел, которые цитировали источник, все, кажется, берут свою мудрость из Статья 2008 года от Стива Соудера. Его выводы основаны на поведении прокси в то время, и они могут или не могут быть актуальными в наши дни. Тем не менее, при отсутствии более текущей информации изменение имени файла является безопасным вариантом.
Безопаснее поставить номер версии в фактическое имя файла. Это позволяет сразу нескольким версиям, чтобы вы могли развернуть новую версию, и если все кэшированные HTML-страницы все еще существуют, которые запрашивают более старую версию, они получат версию, которая работает со своим HTML.
Примечание. , в одном из самых больших версий развертывания в любом месте в Интернете, jQuery использует номера версий в фактическом имени файла, и он надежно позволяет нескольким версиям сосуществовать без какой-либо специальной логики на стороне сервера (каждая версия представляет собой просто другой файл).
Это разрушает кеш один раз при развертывании новых страниц и новых связанных файлов (что вам и нужно), и с тех пор эти версии могут быть эффективно кэшированы (что вам также нужно).
-
1Я согласен с этим, но гораздо проще просто добавить Sinatra? V = & lt;% = VERSION% & gt; для всех запросов css и js, а также для управления каждым файлом по отдельности. В конце концов мы переключимся на синатра-актиппак, который будет предварительно обрабатывать и сжимать все файлы и фактически добавлять версию # к имени файла, что позволит нам управлять ими индивидуально намного проще. – Brad Herman 13 March 2012 в 23:56
-
2Я согласен с тем, что номер версии в имени файла является самым безопасным решением, если вы хотите сделать 10000% уверенным, но я не следую за «несколькими версиями, чтобы существовать сразу», аргумент. URL с параметром запроса отличается от того же URL с другим параметром запроса. Клиент должен рассматриваться как два разных ресурса клиента; если это не так, клиент нарушается. – Pekka 웃 13 March 2012 в 23:58
-
3@Pekka - номер версии может позволить сразу нескольким версиям, но для этого требуется взаимодействие с сервером для сопоставления параметра запроса с правильным фактическим файлом. Я не думаю, что это то, что делает OP, и нет оснований требовать, чтобы это осложнение при изменении имени файла было намного проще и не требует взаимодействия с сервером. Очевидно, оба могут работать. – jfriend00 14 March 2012 в 00:15
В целом это должно быть хорошо, но это возможно, если это не работает, если есть промежуточный кэш (прокси), который настроен на игнорирование параметров запроса.
Например, если вы обслуживая статический контент через CDN Akamai, он может быть настроен на игнорирование параметров запроса для предотвращения перебора кэша с использованием этого метода.
Он разобьет кеш один раз, после того как клиент скачал ресурс, каждый другой ответ будет отправлен из кеша клиента, если только:
- обновлен параметр v.
- клиент очищает свой кеш
Кэш-пакет использует некоторое случайное число в конце URL-адреса, как указано ниже
<script type="text/javascript" language="JavaScript">
ord=Math.random()*10000000000000000;
</script>
, и браузер создает что-то вроде этого,
http://ad.doubleclick.net/ABC/publisher/zone;topic=abc;sbtpc=def;cat=ghi;kw=xyz;tile=1;slot=728x90.1;sz=728x90;ord=7268140825331981?
Подробнее здесь .
-
1Это заставит каждого пользователя повторно загружать файлы JS / CSS каждый раз при загрузке веб-сайта. Браузер кэширует эти файлы по уважительной причине. Хотя это будет работать, это будет невероятно плохая практика: |. – alexbooots 24 December 2017 в 00:35
-
2Да. Я забыл добавить отказ. Несмотря на то, что это не оптимальное решение, но оно также является решением для перебора кеша. – Premkumar30 28 December 2017 в 10:01
Нашли сравнение двух методов (строка запроса vs имя файла) здесь :
Версия в виде запроса имеет две проблемы.
Во-первых, он не всегда может быть браузером, который реализует кеширование, через которое мы должны разрушить. Говорят, что некоторые (возможно, более старые) прокси игнорируют запрос в отношении поведения кэширования.
Во-вторых, в некоторых более сложных сценариях развертывания, где у вас есть несколько интерфейсных и / или множественных серверных серверов, обновление - это не что иное, как мгновенное. Вы должны одновременно использовать как старую, так и новую версию своих активов. См. Например, как это влияет на вас при использовании Google App Engine.
<link rel="stylesheet" href="style.css?v=1487935578" />– oelna 28 February 2017 в 19:50