¿Por qué pasar parámetros a los archivos de enlace de CSS y JavaScript como src = "../ cnt.js? Ver = 4.0"?

Question

Cuando vi el código fuente de muchos sitios, los parámetros se pasaban al archivo de enlace (CSS/JavaScript).

En la fuente de desbordamiento de pila  , tengo

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

¿Por qué se utiliza master.js?v=55c7eccb8e19?

Estoy seguro de que los archivos JavaScript/CSS no pueden obtener los parámetros.

¿Cuál es el motivo?

Answer 1

Por lo general, se realiza para evitar el almacenamiento en caché.

Digamos que implementa la versión 2 de su nueva aplicación y desea hacer que los clientes actualicen su CSS, puede agregar este parámetro adicional para indicar que debe volver a solicitarlo del servidor. Por supuesto, hay otros enfoques también, pero esto es bastante simple.

Answer 2

Un script del lado del servidor que genera el código CSS o JavaScript podría hacer uso de ellos, pero probablemente solo se use para cambiar el URI cuando cambie el contenido del archivo para que las versiones antiguas en caché no causen problemas.

Answer 3

Como han dicho los otros, probablemente sea un intento de controlar el almacenamiento en caché, aunque creo que es mejor hacerlo cambiando el nombre del recurso real (foo.v2.js) en lugar de una versión en la cadena de consulta. (Eso no significa significa que tiene que cambiar el nombre de los archivos, hay mejores formas de asignar esa URL al archivo subyacente.) This article, aunque cuatro años y por lo tanto antigua en el mundo web, sigue siendo una discusión bastante útil . En ella, el autor afirma que no desea utilizar las cadenas de consulta para las versiones porque:

... Según la letra de la especificación de almacenamiento en caché HTTP, agentes de usuario deberían URLs no caché con cadenas de consulta. Mientras que Internet Explorer y Firefox ignoran esto, Opera y Safari no ...

Esta afirmación puede no ser del todo correcta, porque lo que es la especificación actually says

... ya que algunas aplicaciones tienen GET y HEAD utilizados tradicionalmente con URL de consulta (aquellos que contienen un "?" en la parte rel_path) para realizar operaciones con efectos secundarios significativos, las memorias caché NO DEBEN tratar las respuestas a dichos URI como nuevos a menos que el servidor proporcione un tiempo de expiración explícito.

(Ese énfasis al final es mío). Así que usar una versión en la cadena de consulta puede estar bien siempre y cuando también incluyas encabezados de caché explícitos. Los navegadores proporcionados implementan lo anterior correctamente. Y los proxies lo hacen. Verá por qué creo que está mejor con las versiones en el localizador de recursos real, en lugar de los parámetros de consulta (que [nuevamente] no significa significa que tiene que cambiar el nombre de los archivos constantemente; consulte el artículo vinculado más arriba para obtener más información). Usted sabe navegadores, proxies, etc. a lo largo del camino va a buscar el recurso actualizado si cambia su nombre, lo que significa que puede darle al "nombre" anterior un tiempo de caché interminable para maximizar el beneficio de las cachés intermedias.

Con respecto a:

Estoy seguro de que los archivos JS/CSS no pueden obtener los parámetros.

El hecho de que el resultado sea un recurso JavaScript o CSS, no significa que sea un archivo literal en el sistema de archivos del servidor. El servidor podría estar procesando según los parámetros de cadena de consulta y generando una respuesta personalizada de JavaScript o CSS. No hay ninguna razón por la que no pueda configurar mi servidor para enrutar todos los archivos .js a (digamos) un controlador de PHP que examina la cadena de consulta y devuelve algo personalizado para que coincida con los campos especificados. Por lo tanto, foo.js?v=2 bien puede ser diferente de foo.js?v=1 si configuré mi servidor para hacerlo.

Answer 4

Esto es para obligar al navegador a volver a almacenar en caché el archivo .js si se ha producido alguna actualización.

Verá, cuando actualiza su JS en un sitio, algunos navegadores pueden haber guardado en caché la versión anterior (para mejorar el rendimiento). Si desea que utilicen su nuevo, puede agregar algo en el campo de consulta del nombre y ¡voíla! ¡El navegador recupera el archivo!

Esto se aplica a todos los archivos enviados desde el servidor por cierto.

Answer 5

Eso es para evitar que el navegador guarde en caché el archivo. El nombre de la versión anexa no tiene ningún efecto en el archivo JavaScript, pero el motor de almacenamiento en caché del navegador ahora parece un archivo único.

Por ejemplo, si tenía scripts.js y el navegador visita la página, descargan y almacenan (guardan) en caché ese archivo para hacer que la visita de la página siguiente sea más rápida. Sin embargo, si realiza un cambio, es posible que el navegador no lo reconozca hasta que el caché haya expirado. Sin embargo, scripts.js?v2 ahora hace que el navegador fuerce una recuperación porque el "nombre ha cambiado" (aunque no lo haya hecho, solo los contenidos).

Answer 6

Dado que los archivos javascript y css se almacenan en caché por el navegador del cliente, por lo que anexar algunos valores numéricos en contra de sus nombres con el fin de proporcionar la versión no-caché del archivo

Answer 7

"Estoy seguro de que JavaScript archivos/CSS no pueden obtener los parámetros"

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 8

Esto se conoce como de almacenamiento en caché.

El navegador guardará en caché el archivo, incluida la cadena de consulta. La próxima vez que se actualice la cadena de consulta, el navegador se verá obligado a descargar la nueva versión del archivo.

Hay varios tipos de almacenamiento en memoria caché, por ejemplo:

• estático
• Fecha/Hora
• versión de software
• hash-contenido

que he escrito un artículo sobre el almacenamiento en memoria caché anteriormente que puede ser útil:

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

Answer 9

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