javascript - style - link button css

¿Por qué pasar parámetros a archivos de enlaces 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, obtuve

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

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

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

¿Cual es la razon?

Answer 1

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

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

... Según la letra de la especificación de almacenamiento en caché de HTTP, los agentes de usuario nunca deben almacenar en caché las URL con cadenas de consulta. Si bien Internet Explorer y Firefox ignoran esto, Opera y Safari no ...

Esa afirmación puede no ser del todo correcta, porque lo que la especificación realmente dice es

... dado que algunas aplicaciones tradicionalmente han usado GET y HEAD con URL de consulta (las que contienen un "?" en la parte rel_path) para realizar operaciones con efectos secundarios significativos, las memorias caché NO DEBEN tratar las respuestas a tales URI como nuevas a menos que el servidor proporcione tiempo expiración explícita ...

(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 (lo que [nuevamente] no significa que tiene que cambiar constantemente el nombre de los archivos, consulte el artículo vinculado más arriba para obtener más información). Sabes que los navegadores, proxies, etc. a lo largo del camino van a buscar el recurso actualizado si cambias su nombre, lo que significa que puedes dar al "nombre" previo un tiempo de caché interminable para maximizar el beneficio de los cachés intermedios.

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 (por ejemplo) un controlador de PHP que examine la cadena de consulta y devuelva 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 3

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 en caché (almacenar) ese archivo para hacer que la visita a 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 4

Esto es para obligar al navegador a volver a almacenar en caché el archivo .js si ha habido 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

Como los archivos javascript y css están en caché en el navegador del cliente, adjuntamos algunos valores numéricos a sus nombres para proporcionar la versión no almacenada en caché del archivo

Answer 6

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

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

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

Answer 8

"Estoy seguro de que los archivos JavaScript / 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 9

Esto se conoce como prevención de 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 prevención de almacenamiento en memoria caché, por ejemplo:

• Estático
• Fecha y hora
• Versión del software
• Hashed-Content

He escrito un artículo sobre prevención de memoria caché anteriormente que puede ser útil:

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