Une brève discussion sur les requêtes Ajax et la mise en cache du navigateur-js tutoriel-php.cn

Une brève discussion sur les requêtes Ajax et la mise en cache du navigateur

韦小宝

Libérer： 2018-01-13 11:42:03

original

1675 Les gens l'ont consulté

L'éditeur suivant vous apportera une brève discussion sur les requêtes Ajax et la mise en cache du navigateur. L'éditeur pense que c'est plutôt bien, alors maintenant je vais partager le code source ajax avec vous et le donner comme référence. Si vous êtes intéressé par ajax, suivez l'éditeur pour y jeter un œil

Dans les applications Web modernes, le code front-end est inondé d'un grand nombre de requêtes Ajax si le cache du navigateur peut être utilisé pour les requêtes Ajax. , il peut être considérablement réduit. Requêtes réseau pour améliorer la vitesse de réponse du programme.

1. Requête Ajax

L'utilisation de jQueryframework peut effectuer des requêtes Ajax très facilement. L'exemple de code est le suivant. :

$.ajax({
  url : &#39;url&#39;,
  dataType : "xml",
  cache: true,
  success : function(xml, status){  
      }
});

Copier après la connexion

est très simple. Faites attention à la 4ème ligne de code : cache: true, qui nécessite explicitement que si la requête actuelle a un cache, utilisez le cache directement. Si l'attribut est défini sur false, cela forcera les pages demandées à ne pas être mises en cache par le navigateur. La définition du cache sur false ajoute également un paramètre de chaîne de requête, "_=[TIMESTAMP]", à l'URL.

Il n'y a qu'une quantité limitée de travail sur le front-end. De cette façon, les requêtes Ajax peuvent-elles profiter du cache du navigateur ?

Continuez à regarder.

2. Protocole Http La partie en-tête du protocole HTTP définit si le client doit mettre en cache et comment le mettre en cache. Pour plus de détails, voir 14.9 Cache-Control et 14.21 Expire les définitions de champ d'en-tête HTTP. Voici une brève explication :

Cache-Control

Cache-control est utilisé pour contrôler le cache HTTP (il peut ne pas être partiellement implémenté dans HTTP/1.0, mais seulement Pragma est implémenté : no-cache)

Format dans le paquet :

Cache-Control : cache-directive

cache-directive peut être le suivant :

Utilisé lors de la demande :

| "no-cache"

| "no-store"

réponse :

| "public"

Description :

-Public indique que la réponse peut être mise en cache par n’importe quelle zone de cache.

-Privé indique que tout ou partie du message de réponse d'un seul utilisateur ne peut pas être partagé

traitement du cache. Cela permet au serveur de décrire uniquement une réponse partielle d'un utilisateur qui n'est pas valide pour les demandes des autres utilisateurs.

-no-cache indique que le message de demande ou de réponse ne peut pas être mis en cache (HTTP/1.0 est remplacé par le no-cache de Pragma

-no-store est utilisé pour empêcher les informations importantes d'être mises en cache). être libéré involontairement. L'envoyer dans le message de demande entraînera l'utilisation de la mise en cache par les messages de demande et de réponse.

-max-age Indique que le client peut recevoir des réponses avec une durée de vie ne dépassant pas le temps spécifié en secondes.

-min-fresh indique que le client peut recevoir des réponses avec un temps de réponse inférieur à l'heure actuelle plus l'heure spécifiée.

-max-stale indique que le client peut recevoir des messages de réponse au-delà du délai d'attente. Si une valeur de message périmée maximale est spécifiée, le client peut

recevoir des messages de réponse qui se situent dans la valeur spécifiée du délai d'expiration.

Expires

Expires représente le temps effectif du Cache, permettant au client de ne pas envoyer de requêtes avant ce délai, ce qui équivaut à l'effet de max- âge. Mais s'ils existent en même temps, ils seront remplacés par l'âge maximum de Cache-Control.

Format : Expire = "Expire" : "Date HTTP
Exemple : Expire : jeu. 01 décembre 1994 16:00:00 GMT

Dernière modification

Last-Modified indique l'heure de la dernière modification du document au format GMT Lorsque le client demande cette URL pour la deuxième fois, un attribut sera ajouté à l'en-tête pour demander si le fichier a été modifié après cette heure. . Si le fichier côté serveur n'a pas été modifié, l'état de retour est 304 et le contenu est vide, économisant ainsi la quantité de données à transmettre.

3. Mon problème

Quand je travaillais sur le front-end Web ces jours-ci, j'ai constaté que chaque requête Ajax du client serait effectuée à partir du serveur, et l'immédiateté de ces données n'est pas si élevée, il n'est pas nécessaire de les demander à chaque fois.

Après avoir explicitement ajouté le cache à Ajax comme étant vrai, j'ai constaté que le problème persistait. J'ai donc soupçonné qu'il s'agissait d'un problème côté serveur. Le serveur a utilisé Jersey pour créer un service basé sur Restful. L'extrait de code est le suivant :

@GET
@Produces("application/xml")
public Response getProducts() {
     Response.ResponseBuilder response = Response.ok(data);
     return response.build();
}

Copier après la connexion

添加Cache控制后，进行测试，一切OK。

最后的代码如下：

@GET
@Produces("application/xml")
public Response getProducts() {
     Response.ResponseBuilder response = Response.ok(data);
     // Expires 3 seconds from now..this would be ideally based
     // of some pre-determined non-functional requirement.
     Date expirationDate = new Date(System.currentTimeMillis() + 3000);
     response.expires(expirationDate);
     return response.build();
}

Copier après la connexion

以上只是示例代码，还可以进行更精细的控制，例如使用CacheControl、Last-Modified等等。