Eine kurze Diskussion über Ajax-Anfragen und Browser-Caching-js-Tutorial-php.cn

Eine kurze Diskussion über Ajax-Anfragen und Browser-Caching

韦小宝

Freigeben： 2018-01-13 11:42:03

Original

1640 Leute haben es durchsucht

Der folgende Editor bietet Ihnen eine kurze Diskussion über Ajax-Anfragen und Browser-Caching. Der Herausgeber findet es ziemlich gut, deshalb teile ich jetzt den Ajax-Quellcode mit Ihnen und gebe ihn als Referenz. Wenn Sie sich für Ajax interessieren, folgen Sie dem Editor, um einen Blick darauf zu werfen.

In modernen Webanwendungen wird der Front-End-Code mit einer großen Anzahl von Ajax-Anfragen überflutet. Wenn der Browser-Cache für Ajax-Anfragen verwendet werden kann , können Netzwerkanfragen erheblich reduziert werden, um die Reaktionsgeschwindigkeit des Programms zu verbessern.

1. Ajax-Anfrage

Mit dem jQueryFramework können Ajax-Anfragen sehr bequem erfolgen :

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

Nach dem Login kopieren

ist sehr einfach. Beachten Sie die 4. Codezeile: cache: true, die ausdrücklich erfordert, dass, wenn die aktuelle Anfrage einen Cache hat, der Cache direkt verwendet werden muss. Wenn das -Attribut auf „false“ gesetzt ist, wird erzwungen, dass angeforderte Seiten nicht vom Browser zwischengespeichert werden. Wenn der Cache auf „false“ gesetzt wird, wird auch ein Abfragezeichenfolgenparameter „_=[TIMESTAMP]“ an die URL angehängt.

Es gibt nur so viel Arbeit am Frontend. Können Ajax-Anfragen auf diese Weise den Browser-Cache nutzen?

Schau weiter.

2. HTTP-Protokoll Der Header-Teil des HTTP-Protokolls definiert, ob und wie der Client zwischenspeichern soll. Einzelheiten finden Sie unter 14.9 Cache-Kontrolle und 14.21 Abläufe von HTTP-Header-Felddefinitionen. Hier eine kurze Erklärung:

Cache-Control

Cache-Control wird zur Steuerung des HTTP-Cache verwendet (es ist möglicherweise nicht teilweise in HTTP/1.0 implementiert, sondern nur Pragma ist implementiert: kein Cache)

Format im Paket:

Cache-Control: Cache-Direktive

Cache-Direktive kann das sein Folgendes:

Wird bei der Anfrage verwendet:

| „no-cache“

|. „max-age“ „= " delta-seconds

sponse:

| „public“

| „private " [ "= " <"> Feldname <"> ]

-Public gibt an, dass die Antwort zwischengespeichert werden kann durch einen beliebigen Cache-Bereich.

-Private gibt an, dass die Antwortnachricht für einen einzelnen Benutzer ganz oder teilweise nicht geteilt werden kann Cache-Verarbeitung

. Dadurch kann der Server nur eine Teilantwort eines Benutzers beschreiben, die für die Anfragen anderer Benutzer nicht gültig ist.

-no-cache gibt an, dass die Anforderungs- oder Antwortnachricht nicht zwischengespeichert werden kann (HTTP/1.0 wird durch Pragmas No-Cache ersetzt).

-no-store wird verwendet, um zu verhindern, dass wichtige Informationen gespeichert werden unbeabsichtigt freigelassen werden. Das Senden in der Anforderungsnachricht führt dazu, dass sowohl die Anforderungs- als auch die Antwortnachrichten Caching verwenden.

-max-age Gibt an, dass der Client Antworten mit einer Lebensdauer empfangen kann, die nicht größer als die angegebene Zeit in Sekunden ist.

-min-fresh gibt an, dass der Client Antworten mit einer Antwortzeit erhalten kann, die kürzer ist als die aktuelle Zeit plus die angegebene Zeit.

-max-stale gibt an, dass der Client über den Timeout-Zeitraum hinaus Antwortnachrichten empfangen kann. Wenn ein maximal veralteter Nachrichtenwert angegeben ist, kann der Client

Antwortnachrichten empfangen, die innerhalb des angegebenen Werts des Timeout-Zeitraums liegen.

Ablaufdatum

Ablaufdatum stellt die effektive Zeit des Caches dar, sodass der Client vor diesem Zeitpunkt keine Anfragen senden kann, was der Wirkung von max. Alter. Wenn sie jedoch gleichzeitig vorhanden sind, werden sie durch das maximale Alter von Cache-Control überschrieben.

Format: Expires = "Expires" ":" HTTP-DatumBeispiel: Läuft ab: Do, 01. Dezember 1994 16:00:00 GMT

Zuletzt geändert

Last-Modified gibt den Zeitpunkt der letzten Änderung des Dokuments im GMT-Format an. Wenn der Client diese URL zum zweiten Mal anfordert, wird ein Attribut zum Header hinzugefügt, um zu fragen, ob die Datei nach diesem Zeitpunkt geändert wurde . Wenn die Datei auf der Serverseite nicht geändert wurde, ist der Rückgabestatus 304 und der Inhalt ist leer, wodurch die zu übertragende Datenmenge gespart wird.

3. Mein Problem

Als ich dieser Tage am Web-Frontend arbeitete, stellte ich fest, dass jede Ajax-Anfrage vom Client Daten vom Server erstellt werden und die Unmittelbarkeit dieser Daten nicht so hoch ist, besteht keine Notwendigkeit, sie jedes Mal anzufordern.

Nachdem ich den Cache für Ajax explizit auf „true“ gesetzt hatte, stellte ich fest, dass das Problem weiterhin bestand. Daher vermutete ich, dass es sich um ein Problem auf der Serverseite handelte. Der Server verwendete Jersey, um einen Restful-basierten Dienst aufzubauen. Der Codeausschnitt lautet wie folgt:

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

Nach dem Login kopieren

添加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();
}

Nach dem Login kopieren

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