Зачем передавать параметры в файлы ссылок CSS и JavaScript, такие как src = "../ cnt.js? Ver = 4.0"?

Question

Когда я увидел исходный код многих сайтов, параметры были переданы в файл ссылок (CSS / JavaScript).

В источнике переполнения стека я получил

<script type="text/javascript" src="http://sstatic.net/js/master.js?v=55c7eccb8e19"></script> 

Почему используется master.js?v=55c7eccb8e19?

Я уверен, что файлы JavaScript / CSS не могут получить параметры.

В чем причина?

Answer 1

Обычно это делается для предотвращения кэширования.

Допустим, вы развернули версию 2 своего нового приложения и хотите, чтобы клиенты обновляли свой CSS, вы можете добавить этот дополнительный параметр, чтобы указать, чтоповторно запросить его с сервера.Конечно, есть и другие подходы, но это довольно просто.

Answer 2

Как уже говорили другие, это, вероятно, попытка контролировать кэширование, хотя я думаю, что лучше всего это сделать, изменив реальное имя ресурса (foo.v2.js, а не foo.js?v=2), а не версию в строке запроса. (То, что не означает, что вам нужно переименовывать файлы, есть более эффективные способы сопоставления этого URL-адреса с базовым файлом.) Эта статья , хотя ей четыре года и, следовательно, Древний в мире Интернета, все еще довольно полезная дискуссия. В нем автор утверждает, что вы не хотите использовать строки запроса для версий, потому что:

... Согласно букве спецификации кэширования HTTP, пользовательские агенты не должны никогда кэшировать URL со строками запроса. Хотя Internet Explorer и Firefox игнорируют это, Opera и Safari не ...

Это утверждение может быть не совсем правильным, потому что то, что в спецификации на самом деле говорит , является

... так как некоторые приложения традиционно использовали GET и HEAD с URL-адресами запросов (те, которые содержат "?" В части rel_path) для выполнения операций со значительными побочными эффектами, кэши НЕ ДОЛЖНЫ обрабатывать ответы на такие URI как свежие если сервер не предоставит явное время истечения ...

(Этот акцент в конце мой.) Поэтому использование версии в строке запроса может быть оправдано, если вы также включите явные заголовки кэширования. При условии, что браузеры реализуют вышеизложенное правильно. И прокси делают. Вы понимаете, почему я думаю, что вам лучше использовать версии в фактическом локаторе ресурсов, а не параметры запроса (что [снова] не означает, что вам нужно постоянно переименовывать файлы; см. Статью, приведенную выше, для Больше). Вы знаете, браузеры, прокси-серверы и т. Д. По пути извлекут обновленный ресурс, если вы измените его имя, что означает, что вы можете дать предыдущему «имени» бесконечное время кэширования, чтобы максимизировать выгоду промежуточных кэшей.

Относительно:

Я уверен, что файлы Js / CSS не могут получить параметры.

То, что возвращаемый результат является ресурсом JavaScript или CSS, не означает, что это буквальный файл в файловой системе сервера. Сервер вполне может выполнять обработку на основе параметров строки запроса и генерировать настраиваемый ответ JavaScript или CSS. Нет причины, по которой я не могу настроить свой сервер для маршрутизации всех файлов .js, скажем, в обработчик PHP, который просматривает строку запроса и возвращает что-то настроенное в соответствии с заданными полями. Таким образом, foo.js?v=2 вполне может отличаться от foo.js?v=1, если я настроил свой сервер для этого.

Answer 3

Это чтобы браузер не кэшировал файл. Добавленное имя версии не влияет на файл JavaScript, но для механизма кэширования браузера оно теперь выглядит как уникальный файл.

Например, если у вас есть scripts.js и браузер посещает страницу, они загружают и кэшируют (сохраняют) этот файл, чтобы ускорить посещение следующей страницы. Однако, если вы сделаете изменение, браузер может не распознать его, пока не истечет срок действия кэша. Тем не менее, scripts.js?v2 теперь заставляет браузер вызывать повторную выборку, потому что «имя изменилось» (хотя это не так, только содержание изменилось).

Answer 4

<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> 

Answer 5

Сценарий на стороне сервера, генерирующий код CSS или JavaScript, мог бы использовать их, но он, вероятно, просто используется для изменения URI, когда изменяется содержимое файла, чтобы старые кэшированные версии не вызывали проблем .

Answer 6

Это заставляет браузер повторно кэшировать файл .js, если было какое-либо обновление.

Видите ли, когда вы обновляете свой JS на сайте, некоторые браузеры могли кэшировать старую версию (для повышения производительности).Так как вы хотите, чтобы они использовали ваш новый, вы можете добавить что-то в поле запроса имени, и вуаля!Браузер повторно выбирает файл!

Это относится ко всем файлам, отправленным с сервера между прочим.

Answer 7

Это называется Очистка кэша .

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

Существуют различные типы очистки кэша, например:

• Статический
• Дата / Время
• Версия программного обеспечения
• Hashed-Content

Ранее я написал статью о разрушении кэша, которая может оказаться вам полезной:

http://curtistimson.co.uk/front-end-dev/what-is-cache-busting/

Answer 8

"Я уверен, что JavaScript / CSS-файлы не могут получить параметры"

function getQueryParams(qs) {
    qs = qs.split("+").join(" ");
    var params = {},
        tokens, re = /[?&]?([^=]+)=([^&]*)/g;
    while (tokens = re.exec(qs)) {
        params[decodeURIComponent(tokens[1])] = decodeURIComponent(tokens[2]);
    }
    return params;
}

Answer 9

Поскольку файлы javascript и css кэшируются браузером клиента, поэтому мы добавляем некоторые числовые значения к их именам, чтобы обеспечить некэшируемую версию файла