[Javascript] Se souvenir d'un fichier chargé dynamiquement ?

[Ter Rowan]

Bonjour, je me posais la question suivante :

Supposons que je charge dynamiquement un fichier Javascript

Exemple

J aimerais savoir si ce fichier est conservé en cache par le navigateur

D ailleurs comment tester soi meme ce genre de comportement ?

[Akira777]

Hum, en le chargeant via l'objet XHR tu peux choisir d'utiliser le cache du navigateur.

Je sais pas faire en JS pur donc je te donne un exemple utilisant jQuery, je suppose que c'est équivalent (je précise que je suis pas hyper-calé non plus dans le domaine)

Code :

$.ajax({type: "GET",url: "test.js",cache: false, dataType: "script"});

[Plume]

Il n'y a pas de réelle façon de savoir via JavaScript si un fichier est dans le cache d'un navigateur.

Soit tu te bases sur le temps de chargement d'une ressource, mettons 25 millisecondes, pour savoir si elle est chargée localement mais tu auras 2 problèmes :

• Une ressource externe peut être chargée dans ce labs de temps;
  
• Une ressource interne peut dépasser le seuil prédéfini;

Soit tu te bases sur les entêtes HTTP d'une requête d'une ressource. Le seul problème, c'est qu'à l'heure actuelle, je n'ai pas trouvé de moyen de traiter ces informations via un objet XMLHttpRequest. Par exemple, une requête pour une ressource en cache aura un status 304 Not Modified.

On peut envisager également que tu trouves la variable Cache-Control dans l'entête HTTP. Elle peut te renseigner sur la durée de vie du fichier dans le cache (eg. max-age=0) de ton navigateur. Toutes les informations sur Cache-Control sont sur le site du W3C : http://www.w3.org/Protocols/rfc2616/rfc2...ml#sec14.9. Tu verras que tu peux avoir beaucoup plus d'informations concernant la gestion d'une ressource via le cache de ton navigateur.

Sauf erreur de ma part, par défaut, les ressources JavaScript sont stockées dans le cache du navigateur. Toutefois, une requête non cachée ira chercher les ressources dont elle a besoin sur le serveur.

Au final, je ne pense pas qu'on soit en mesure de te fournir une vraie réponse. J'aurai pensé que les requêtes faites via l'objet HMLHttpRequest serait soumises au cache du navigateur, ce que je crois est bel et bien le cas, mais tu auras toujours un status valant 200. Donc inutile pour ce que tu demandes.

Bref.

Désolé…

[Maks]

Soit tu te bases sur les entêtes HTTP d'une requête d'une ressource. Le seul problème, c'est qu'à l'heure actuelle, je n'ai pas trouvé de moyen de traiter ces informations via un objet XMLHttpRequest

Il me semble que le XHR niveau 2 le permet ?

Sinon faut tester xhr.status === 304 après une courte recherche ça parait possible, malgré un bug sous Opera.

[Plume]

@Maks : J'ai testé sous Chrome et Firefox et ça ne marche pas. Ni l'un (accès au statut de la requête dans les entêtes HTTP), ni l'autre (xhr.status).

Le code ressemble à :

var request = new XMLHttpRequest(), headers;

request.open('HEAD', resourceURL, false);

request.send(null);



headers = request.getAllResponseHeaders();

console.log(headers);

[Maks]

xhr = new XMLHttpRequest

xhr.open 'GET', 'http://127.0.0.1:8080/public/js/class/Map.js', false

xhr.send null

console.log xhr.getAllResponseHeaders()

J'obtiens sans vider le cache (statut 304)

X-Powered-By: Express
Date: Mon, 06 Aug 2012 14:46:21 GMT
Cache-Control: public, max-age=0
Last-Modified: Mon, 06 Aug 2012 12:40:55 GMT
Etag: "16747-1344256855000"
Content-Type: application/javascript
Accept-Ranges: bytes
Content-Length: 16747

Après avoir vidé le cache (statut 200)

X-Powered-By: Express
Date: Mon, 06 Aug 2012 14:47:39 GMT
Cache-Control: public, max-age=0
Last-Modified: Mon, 06 Aug 2012 12:40:55 GMT
Etag: "16747-1344256855000"
Content-Type: application/javascript
Accept-Ranges: bytes
Content-Length: 16747
Connection: keep-alive

Dans mon cas la présence de "Connection: keep-alive" peut donner une indication sur le statut donc, mais cela vient peut être de ma configuration de Express

Plus généralement pour éviter la mise en cache, on utilise le timestamping d'URL, c'est ce que fait l'option cache:false de jQuery qui donne une url de type 'http://url.com?' + Date.now()
Théoriquement le fichier est tout le temps mis en cache, sauf si le cache est plein ?
Le lien donné au début du topic c'est le même principe que le JSON Polling il me semble, on ajoute dynamiquement du contenu dans le head. Les fichiers sont mis en cache il me semble via cette méthode (à confirmer) comme pour la voie "classique" d'inclusion de fichiers JS.
Après quel intérêt de savoir si le fichier est en cache ou non ?

[Plume]

On est d'accord pour dire que le statut de la requête n'apparait pas dans les entêtes HTTP ?

[Ter Rowan]

Plop merci pour vos retours, ça me rassure un peu

Après quel intérêt de savoir si le fichier est en cache ou non ?

Pour des questions d optimisation

Je souhaite créer une appui avec des ressources textes coté client, et n envoyer en Ajax (ou ajaj) que des références (des nombres quoi)

L intérêt que j y vois est que les textes ne sont chargés qu une fois, a la premiere connexion
Après les messages sont réduits :

Au lieu de "vous avez supprimé 3746 zogzog, ce qui est vraiment magnifique, ne trouvez vous pas ?"

Le message envoyé serait "32,3746,34", plus petit
Si on considère que 32 est la clef du message, 3746 le premier parametre et 34 la clef pour zogzog

L optimisation ne vaut que si la table de référence n est chargée qu une fois
Donc il me faut savoir si on est en cache ou non (et j aimerai devenir autonome sur cela, pas vous demander a chaque idée /essai )

[Plume]

Plus généralement pour éviter la mise en cache, on utilise le timestamping d'URL […]

Oui, je connais bien cette pratique. Elle est également utilisée côté serveur pour forcer le navigateur à rafraichir la ressource dans son cache, as we both know.

Théoriquement le fichier est tout le temps mis en cache, sauf si le cache est plein ?

C'est ça.

Le lien donné au début du topic c'est le même principe que le JSON Polling il me semble, on ajoute dynamiquement du contenu dans le head. Les fichiers sont mis en cache il me semble via cette méthode (à confirmer) comme pour la voie "classique" d'inclusion de fichiers JS.

Toujours exact.

Après quel intérêt de savoir si le fichier est en cache ou non ?

Le savoir, pas à grand chose, AMHA.

L intérêt que j y vois est que les textes ne sont chargés qu une fois, a la premiere connexion
Après les messages sont réduits :

Au lieu de "vous avez supprimé 3746 zogzog, ce qui est vraiment magnifique, ne trouvez vous pas ?"

Le message envoyé serait "32,3746,34", plus petit
Si on considère que 32 est la clef du message, 3746 le premier parametre et 34 la clef pour zogzog

Pour ce genre de chose, tu devrais considérer le templating côté client.

Regarde ce genre de chose :

• http://handlebarsjs.com/
  
• http://backbonejs.org/
  
• http://mustache.github.com/

En gros, tu déportes l'affichage sur le client et ton serveur ne fait plus que fournir une API. Ainsi, tu économises sur beaucoup de choses (bande passante, nombre de requête,…).

Enjoy!

[Ter Rowan]

Merci je vais regarder cela