Ajax要求とブラウザキャッシュ
近代的なWebアプリケーションでは、フロントエンドコードは、Ajax要求に対してブラウザキャッシュを使用することができる場合、ネットワーク要求を著しく低減し、プログラム応答速度を向上させるために、大量のAjax要求に満ちている。
1.Ajax Request
jQueryフレームを使用して、Ajax要求を簡単に行うことができます。例のコードは以下の通りです。
If set to false,it will force requested pages not to be cached by the browser.Setting cache to false also apends a query streing parameter,「u=[u]TIMESTAMP",to the URL.
フロントエンドの仕事もこんなに多くなりました。これでAjax要求はブラウザキャッシュを利用できますか?
続きを見る。
2.Http契約
Httpプロトコルのheader部分は、クライアントがCacheを行うべきかどうかを定義し、どのようにCacheを行うべきかを定義している。具体的にはHttp Header Field Definitionsの14.9 Cache-Coontrolと14.21 Expiresを参照してください。ここで簡単に話してください。
Cache-Coontrol
Cache-controlはHTTPキャッシュを制御するために用いられている(HTTP/1.0では一部実装されていない可能性があり、Pragma:no-cacheのみを実現した)
パケットのフォーマット:
Cache-Coontrol:cache-directive
cache-directiveは以下のようにすることができます。
requestを使う時:
|「no-cache」
|「no-store」
|「max-age」=「delta-seconds」
|「max-stale」[="delta-seconds]
|「min-fresh」「=」delta-seconds
|「no-transform」
|「only-if-cached」
|「cache-extension」
レスポンス時に使用する:
|「public」
|「prvate」[=]<>field-name<>
|「no-cache」[=]<>「field-name」]
|「no-store」
|「no-transform」
|「must-revalidate」
|「proxy-revalidate」
|「max-age」=「delta-seconds」
|「s-maxage」=「delta-seconds」
|「cache-extension」
説明:
-Public 指示応答は、任意のキャッシュ領域によってキャッシュされてもよい。
-Private 単一のユーザに対する応答メッセージの全体または部分を示し、キャッシュ処理を共有できない。これにより、サーバは、ユーザの応答メッセージの一部のみを記述することができ、この応答メッセージは他のユーザの要求に対して無効となる。
-no-cache 指示要求または応答メッセージがキャッシュできない(HTTP/1.0はPragmaのno-cacheで置換される)
-no-store 重要な情報が不用意に発表されるのを防ぐために使われます。要求メッセージの送信は、要求と応答メッセージがキャッシュを使用しないようにする。
-max-age クライアントが指定された時間(秒単位)よりも生存期間が大きい応答を受信できることを示す。
-min-fsh クライアントが応答時間が現在の時間より小さいこと、指定された時間の応答を受信できることを示す。
-max-stale クライアントがタイムアウト中の応答メッセージを受信できることを示す。max-staleメッセージの値を指定すると、クライアントは、
超時間指定値を超えた応答メッセージを受信する。
エクスプレス
Expiresは、Cacheの有効時間を表し、クライアントがこの時間までに要求を送信しないようにすることができます。max-ageの効果と同じです。しかし同時に存在すれば、Cache-Coontrolのmax-ageによってカバーされる。
フォーマット:Expires=「Expires」「:」HTTP-date
例:Expires:Thu,01 Dec 1994 16:00 GMT
Last-Maodified
Last-MaodifiedはGMT形式で文書の最終修正時間を示しています。クライアントはこのURLを2回目に要求すると、ヘッダに属性を追加して、その時間後にファイルが修正されたかどうかを問い合わせることができます。サーバ端のファイルが修正されていない場合、返信状態は304で、コンテンツが空であるため、データの転送量が節約される。
3.私の質問
ここ数日、Webフロントエンドをしていると、クライアントのAjaxはサーバからデータを要求していますが、これらのデータの即時性はそんなに高くなく、毎回要求する必要はありません。
明示的にAjaxにcacheをtrueとした後、問題は依然として発見されました。従って、サービスの問題であると疑われています。サービス側はJereyを使って、Restfulに基づくサービスを構築しました。コードの断片は以下の通りです。
最後のコードは以下の通りです。
以上のこの浅談Ajax要求とブラウザーキャッシュは小編集で皆さんに提供した内容の全部です。参考にしてほしいです。どうぞよろしくお願いします。
1.Ajax Request
jQueryフレームを使用して、Ajax要求を簡単に行うことができます。例のコードは以下の通りです。
$.ajax({
url : 'url',
dataType : "xml",
cache: true,
success : function(xml, status){
}
});
非常に簡単です。その中の4行目のコードに注意してください。cache:true、明示的な要求がキャッシュされていれば、そのままキャッシュを使用します。このプロパティがfalseに設定されていると、毎回サーバに要求されます。JqueryのCommentsは以下の通りです。If set to false,it will force requested pages not to be cached by the browser.Setting cache to false also apends a query streing parameter,「u=[u]TIMESTAMP",to the URL.
フロントエンドの仕事もこんなに多くなりました。これでAjax要求はブラウザキャッシュを利用できますか?
続きを見る。
2.Http契約
Httpプロトコルのheader部分は、クライアントがCacheを行うべきかどうかを定義し、どのようにCacheを行うべきかを定義している。具体的にはHttp Header Field Definitionsの14.9 Cache-Coontrolと14.21 Expiresを参照してください。ここで簡単に話してください。
Cache-Coontrol
Cache-controlはHTTPキャッシュを制御するために用いられている(HTTP/1.0では一部実装されていない可能性があり、Pragma:no-cacheのみを実現した)
パケットのフォーマット:
Cache-Coontrol:cache-directive
cache-directiveは以下のようにすることができます。
requestを使う時:
|「no-cache」
|「no-store」
|「max-age」=「delta-seconds」
|「max-stale」[="delta-seconds]
|「min-fresh」「=」delta-seconds
|「no-transform」
|「only-if-cached」
|「cache-extension」
レスポンス時に使用する:
|「public」
|「prvate」[=]<>field-name<>
|「no-cache」[=]<>「field-name」]
|「no-store」
|「no-transform」
|「must-revalidate」
|「proxy-revalidate」
|「max-age」=「delta-seconds」
|「s-maxage」=「delta-seconds」
|「cache-extension」
説明:
-Public 指示応答は、任意のキャッシュ領域によってキャッシュされてもよい。
-Private 単一のユーザに対する応答メッセージの全体または部分を示し、キャッシュ処理を共有できない。これにより、サーバは、ユーザの応答メッセージの一部のみを記述することができ、この応答メッセージは他のユーザの要求に対して無効となる。
-no-cache 指示要求または応答メッセージがキャッシュできない(HTTP/1.0はPragmaのno-cacheで置換される)
-no-store 重要な情報が不用意に発表されるのを防ぐために使われます。要求メッセージの送信は、要求と応答メッセージがキャッシュを使用しないようにする。
-max-age クライアントが指定された時間(秒単位)よりも生存期間が大きい応答を受信できることを示す。
-min-fsh クライアントが応答時間が現在の時間より小さいこと、指定された時間の応答を受信できることを示す。
-max-stale クライアントがタイムアウト中の応答メッセージを受信できることを示す。max-staleメッセージの値を指定すると、クライアントは、
超時間指定値を超えた応答メッセージを受信する。
エクスプレス
Expiresは、Cacheの有効時間を表し、クライアントがこの時間までに要求を送信しないようにすることができます。max-ageの効果と同じです。しかし同時に存在すれば、Cache-Coontrolのmax-ageによってカバーされる。
フォーマット:Expires=「Expires」「:」HTTP-date
例:Expires:Thu,01 Dec 1994 16:00 GMT
Last-Maodified
Last-MaodifiedはGMT形式で文書の最終修正時間を示しています。クライアントはこのURLを2回目に要求すると、ヘッダに属性を追加して、その時間後にファイルが修正されたかどうかを問い合わせることができます。サーバ端のファイルが修正されていない場合、返信状態は304で、コンテンツが空であるため、データの転送量が節約される。
3.私の質問
ここ数日、Webフロントエンドをしていると、クライアントのAjaxはサーバからデータを要求していますが、これらのデータの即時性はそんなに高くなく、毎回要求する必要はありません。
明示的にAjaxにcacheをtrueとした後、問題は依然として発見されました。従って、サービスの問題であると疑われています。サービス側はJereyを使って、Restfulに基づくサービスを構築しました。コードの断片は以下の通りです。
@GET
@Produces("application/xml")
public Response getProducts() {
Response.ResponseBuilder response = Response.ok(data);
return response.build();
}
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();
}
以上は単なるコード例であり、CachControl、Last-Maodifiedなど、より細かい制御を行うことができる。以上のこの浅談Ajax要求とブラウザーキャッシュは小編集で皆さんに提供した内容の全部です。参考にしてほしいです。どうぞよろしくお願いします。