【4日間で学ぶajax】Ajaxチュートリアル3日目、Ajaxの高度なリクエストとレスポンス

多くの Web 開発者にとっては、単純なリクエストを生成し、単純な応答を受信するだけで十分ですが、Ajax をマスターしたい開発者にとっては、HTTP ステータス コード、準備完了状態、および XMLHttpRequest オブジェクトを完全に理解する必要があります。この記事では、Brett McLaughlin がさまざまなステータス コードを紹介し、ブラウザーがそれらをどのように処理するかを示し、Ajax で使用されるあまり一般的ではない HTTP リクエストのいくつかについても説明します。

このシリーズの前の記事では、XMLHttpRequest オブジェクトについて詳しく説明しました。このオブジェクトは、Ajax アプリケーションの中心であり、サーバー側のアプリケーションおよびスクリプトからのリクエストの処理と、サーバー側のコンポーネントから返されたデータの処理を担当します。すべての Ajax アプリケーションは XMLHttpRequest オブジェクトを使用するため、Ajax のパフォーマンスを向上させるために、このオブジェクトについてよく理解しておくとよいでしょう。

この記事では、前の記事に基づいて、このリクエスト オブジェクトの 3 つの主要な部分に焦点を当てます

。 · HTTP 準備完了ステータス · HTTP ステータス コード · 生成可能なリクエスト タイプ

これら 3 つの部分はすべて、考慮すべき要素を構築する際に含まれます

しかし、リクエストしたとき、これらのトピックについてはあまりにも書かれていませんでした。ただし、Ajax プログラミングの基本以上のことを学びたい場合は、準備完了状態、ステータス コード、およびリクエスト自体の内容をよく理解する必要があります。アプリケーションで問題が発生した場合、常に問題が発生しますが、準備状態、HEAD リクエストの生成方法、ステータス コード 400 の正確な意味を正しく理解していれば、5 時間かかる問題ではなく 5 分で問題をデバッグできます。さまざまな挫折や混乱の中で。

まず、HTTP の準備完了状態を見てみましょう。

HTTP の準備完了状態を詳しく見てみる

前回の記事から、XMLHttpRequest オブジェクトにはreadyState というプロパティがあることを覚えているでしょう。この属性は、サーバーがリクエストを完了したことを保証します。通常はコールバック関数を使用してサーバーからデータを読み取り、Web フォームまたはページのコンテンツを更新します。リスト 1 は、簡単な例を示しています (これは、このシリーズの前の記事の例でもあります。「参考文献」を参照してください)。

XMLHttpRequest または XMLHttp: 名前の変更

Microsoft™ および Internet Explorer は、Mozilla、Opera、Safari、および Microsoft 以外のほとんどのブラウザーで使用される XMLHttpRequest オブジェクトの代わりに、XMLHttp と呼ばれるオブジェクトを使用します。わかりやすくするために、両方のオブジェクトを単に XMLHttpRequest と呼びます。これは、Web 上で見られる内容と、Internet Explorer 7.0 で XMLHttpRequest を要求オブジェクトとして使用するという Microsoft の意図の両方と一致しています。 (この問題の詳細については、パート 2 を参照してください。)

関数 updatePage() {

でサーバーの応答を処理する

if (request.readyState == 4) {
if (request.status == 200) {
var 応答 = request.responseText.split("|");
document.getElementById("order").value = 応答[0];
document.getElementById("アドレス").innerHTML =
response[1].replace(/n/g, "<br />");
} それ以外
alert("ステータスは " + request.status);
}
これ

は明らかに、準備完了状態の最も一般的な (そして最も単純な) 使用法です。数字の「4」からわかるように、他にもいくつかの準備完了状態があります (このリストは前の記事にもあります - 「参考文献」を参照)。

· 0: リクエストは初期化されていません (open() はまだ呼び出されていません)。 。
·1: リクエストは確立されていますが、送信されていません (send() がまだ呼び出されていません)。
·2: リクエストは送信され、処理中です (通常、コンテンツ ヘッダーは応答から取得できます)。
·3: リクエストは処理中です。通常、応答にはデータが含まれていますが、サーバーはまだ応答の生成を完了していません。
·4: 応答が完了しました。サーバーの応答を取得して使用できます。

Ajax プログラミングの基本以上のことを理解したい場合は、これらの状態だけでなく、それらの状態がいつ発生するか、およびその使用方法についても知る必要があります。まず、各準備状態でどのような要求状態が発生する可能性があるかを知る必要があります。残念ながら、これは直感的ではなく、いくつかの特殊なケースが関係します。

隠された準備完了状態

最初の準備完了状態は、readyState 属性が 0 (readyState == 0) であることによって特徴付けられ、初期化されていない状態を示します。リクエスト オブジェクトで open() が呼び出されると、このプロパティは 1 に設定されます。通常、リクエストのペアを初期化した直後に open() を呼び出すため、readyState == 0 状態が表示されることはほとんどありません。さらに、初期化されていない準備完了状態は、実際のアプリケーションでは実際には使用されません。

ただし、興味深いので、readyState が 0 に設定されている場合にこの準備完了状態を取得する方法を示すリスト 2 を参照してください。

リスト 2. 0 の準備完了ステータスの取得

関数 getSalesData() {
//リクエストオブジェクトを作成する
createRequest();
alert("準備完了状態は次のとおりです: " + request.readyState)

// リクエストをセットアップ（初期化）します。
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);

、

リクエスト (ボタンがクリックされたときなど) を開始するために Web ページが呼び出す関数です。 open() を呼び出す前に、準備完了ステータスを確認する必要があることに注意してください。図 1 は、このアプリケーションを実行した結果を示しています。

図 1. 準備完了状態 0

明らかに、これはあまり意味がありません。open() 関数がまだ呼び出されていないかどうかを確認する必要がある状況はほとんどありません。実際のほとんどの Ajax プログラミングでは、この準備完了状態の唯一の用途は、同じ XMLHttpRequest オブジェクトを使用して、複数の関数にわたって複数のリクエストを生成することです。この (まれな) ケースでは、新しいリクエストを生成する前に、リクエスト オブジェクトが初期化されていない状態 (readyState == 0) であることを確認する必要があるかもしれません。これにより、基本的に、別の関数がそのオブジェクトを同時に使用しないことが保証されます。

処理中のリクエストの準備状態を表示します

。リクエスト オブジェクトは、準備完了状態 0 に加えて、一般的なリクエストと応答の他のいくつかの準備完了状態を経る必要があり、最終的に準備完了状態 4 の形で終了します。ほとんどのコールバック関数で if (request.readyState == 4) という行が表示されるのはこのためです。これは、サーバーがリクエストの処理を完了し、Web ページを更新したり、返されたリクエストに基づいてページを安全に更新したりできることを保証します。サーバーからデータを取得して操作を実行します。

この状態がどのように発生するかを確認するのは非常に簡単です。準備完了ステータスが 4 の場合、コールバック関数内のコードを実行する必要があるだけでなく、コールバック関数が呼び出されるたびに準備完了ステータスを出力する必要もあります。 リスト 3 は、この機能の実装例を示しています。

0 が 4 に等しい場合

、複数の JavaScript 関数が同じリクエスト オブジェクトを使用する場合、準備完了ステータス 0 をチェックしてリクエスト オブジェクトが使用されていないことを確認する必要があります。このメカニズムにより問題が発生する可能性があります。 readyState == 4 は完了したリクエストを表すため、現在使用されていない準備完了状態のリクエスト オブジェクトが依然として 4 に設定されていることがよくあります。これは、サーバーから返されたデータがすでに使用されているためです。変更は準備完了状態に設定されてから行われています。リクエストオブジェクトをリセットする関数 abort() がありますが、この関数は実際にはこの目的には使用されません。複数の関数を使用する必要がある場合は、複数の関数間で同じオブジェクトを共有するのではなく、関数ごとに 1 つの関数を作成して使用することをお勧めします。

リスト 3. ビューの準備

関数 updatePage() {
// 現在の準備完了状態を出力します
alert("updatePage() が準備完了状態の " + request.readyState で呼び出されました);

この関数の実行方法がわからない場合は、関数を作成し、Web ページでこの関数を呼び出してサーバー側コンポーネント (リスト 2 に示す関数など) にリクエストを送信させる必要があります

。

このシリーズの記事の関数) 例はパート 1 とパート 2 に示されています)。リクエストを行うときは必ずコールバック関数を updatePage() に設定してください。これを行うには、リクエスト オブジェクトの onreadystatechange プロパティを updatePage() に設定します。

このコードは、onreadystatechange の意味を正確に示しています。リクエストの準備完了状態が変化するたびに、updatePage() が呼び出され、警告が表示されます。図 2 は、準備完了ステータスが 1 の場合のこの関数の呼び出し例を示しています。

図 2. 準備完了状態 1

このコードを自分で実行してみることができます。これを Web ページに配置し、イベント ハンドラーをアクティブにします (ボタンをクリックするか、フィールド間のタブをクリックするか、リクエストをトリガーするために設定したメソッドを使用します)。このコールバック関数は、準備完了状態が変化するたびに複数回実行され、準備完了状態ごとに警告が表示されます。これは、リクエストが通過するさまざまな段階を追跡する最良の方法です。

ブラウザの不一致

プロセスの基本を理解したら、いくつかの異なるブラウザからページにアクセスしてみてください。ブラウザーがこれらの準備完了状態を処理する方法に一貫性がないことに注意してください。たとえば、Firefox 1.5 では、次の準備完了状態が表示されます。

·1
·2
·3
·4

ここでは各リクエストのステータスが表されているため、これは驚くべきことではありません。ただし、Safari を使用して同じアプリケーションにアクセスすると、興味深いものが表示されるかどうかはわかりません。 Safari 2.0.1 では次のようになります:

·2
·3
·4

Safari は実際に最初の準備完了状態を破棄します。明確な理由はありませんが、それが Safari の仕組みです。これは重要な点も示しています。サーバー上のデータを使用する前にリクエストのステータスが 4 であることを確認することは良いことですが、各移行準備完了状態に依存するように記述されたコードは、実際にはブラウザーによって結果が異なります。

たとえば、Opera 8.5 を使用している場合、表示される準備状況はさらに悪くなります:

·3
·

4最後に、Internet Explorer には次のステータスが表示されます。

·1
·2
·3
·4

リクエストに問題がある場合、これが問題を特定する最初の場所です。最善の方法は、Internet Explorer と Firefox の両方でこれをテストすることです。4 つの状態がすべて表示され、リクエストの各状態がどのようなものであるかを確認できます。

次に、対応面の状況を見てみましょう。

顕微鏡で見る応答データ

要求プロセス中に発生するさまざまな準備状態を理解したら、XMLHttpRequest オブジェクトの別の側面、responseText 属性を見てみましょう。前回の記事で紹介したことを思い出してください。この属性はサーバーからデータを取得するために使用されることがわかります。サーバーがリクエストの処理を完了すると、リクエスト データに応答するために必要なデータをリクエストの responseText に配置できます。リスト 1 とリスト 4 に示すように、コールバック関数はこのデータを使用できます。

リスト 4. サーバーで返された応答の使用

関数 updatePage() {
if (request.readyState == 4) {
var newTotal = request.responseText;
var totalSoldEl = document.getElementById("販売合計");
var netProfitEl = document.getElementById("純利益");
replaceText(totalSoldEl, newTotal);

/* 新しい純利益を計算します */
var boardCostEl = document.getElementById("ボードコスト");
var boardCost = getText(boardCostEl);
var manCostEl = document.getElementById("人コスト");
var manCost = getText(manCostEl);
varprofitPerBoard = BoardCost - manCost;
var netProfit =profitPerBoard * newTotal;

/* 販売フォームの純利益を更新します */
netProfit = Math.round(netProfit * 100) / 100;
replaceText(netProfitEl, netProfit);
リスト

1 はかなり単純ですが、リスト 4 は少し複雑ですが、どちらも最初に準備完了状態をチェックし、responseText プロパティの値を取得します。

リクエストの応答テキストの表示

準備完了状態と同様に、responseText プロパティの値もリクエストの存続期間を通じて変化します。この変更を確認するには、リスト 5 に示すコードを使用して、リクエストの応答テキストとその準備ステータスをテストします。

リスト 5. responseText プロパティ

関数のテスト updatePage() {
// 現在の準備完了状態を出力します
alert("updatePage() が準備完了状態で呼び出されました。" + request.readyState +
" と応答テキスト '" + request.responseText + "'");

、

ブラウザで Web アプリケーションを開き、リクエストをアクティブ化します。このコードの効果をよりよく確認するには、Firefox または Internet Explorer を使用してください。どちらのブラウザでも、リクエスト中に考えられるすべての準備状態を報告できるためです。たとえば、準備完了状態 2 では、responseText が定義されていません (図 3 を参照)。JavaScript コンソールも開いていると、エラーが表示されます。

図 3. 準備完了ステータス 2 の応答テキスト

ただし、準備完了状態 3 では、少なくともこの例では、サーバーは responseText プロパティに値を設定しています (図 4 を参照)。

図 4. 準備完了ステータス 3 の応答テキスト

準備完了ステータス 3 の応答は、スクリプトごと、サーバーごと、さらにはブラウザごとに異なることがわかります。ただし、これはアプリケーションのデバッグには依然として非常に役立ちます。

安全なデータの取得

すべての文書と仕様は、準備状況が 4 の場合にのみデータを安全に使用できることを強調しています。信じてください、準備完了状態が 3 の場合、responseText プロパティからデータを取得できない状況はほとんど発生しません。ただし、アプリケーション内で独自のロジックを準備完了状態 3 に依存させるのは得策ではありません。準備完了状態 3 の完全なデータに依存するコードを作成すると、その時点で不完全なデータに対する責任がほとんど発生します。

より良いアプローチは、準備完了状態 3 になったらすぐに応答するというフィードバックをユーザーに提供することです。 alert() のような関数を使用するのは明らかに悪い考えですが、Ajax を使用して警告ダイアログ ボックスでユーザーをブロックするのは明らかに間違っていますが、準備完了状態が変化したときにフォームまたはページ内のフィールドを更新できます。たとえば、準備完了状態 1 の場合は進行状況インジケータの幅を 25% に設定し、準備完了状態 2 の場合は進行状況インジケータの幅を 50% に設定し、準備完了状態 3 の場合は進行状況インジケータの幅を 25 に設定します。 %。幅は 75% に設定され、準備完了状態が 4 の場合、進行状況インジケータの幅は 100% (完了) に設定されます。

もちろん、すでに見たように、この方法は非常に賢いですが、ブラウザーに依存します。 Opera では最初の 2 つの準備完了状態は表示されず、Safari では最初の準備完了状態 (1) が表示されません。このため、このコードは練習用として残し、この記事には含めませんでした。

次に、ステータス コードを見てみましょう。

HTTP ステータス コードの詳細

Ajax プログラミング テクニックで学習した準備完了状態とサーバーの応答を利用して、HTTP ステータス コードを使用して、Ajax アプリケーションにさらに複雑なレベルを追加できます。このコードには Ajax に関する新しい点はありません。これらは Web の黎明期から存在しています。 Web ブラウザでいくつかのステータス コードを見たことがあるかもしれません。

· 401: Unauthorized · 403: Forbidden · 404: Not Found

さらにステータス コードを見つけることができます (完全なリストについては、「参考文献」を参照してください)。追加の制御層と応答 (およびより堅牢なエラー処理) メカニズムを Ajax アプリケーションに追加するには、要求と応答のステータス コードを適切に表示する必要があります。

200: すべて OK

多くの Ajax アプリケーションでは、リスト 6 に示すように、準備状況を確認し、サーバー応答から返されたデータの利用を継続するコールバック関数が表示されます。

リスト 6. ステータス コードを無視するコールバック関数

function updatePage() {
if (request.readyState == 4) {
var 応答 = request.responseText.split("|");
document.getElementById("order").value = 応答[0];
document.getElementById("アドレス").innerHTML =
response[1].replace(/n/g, "<br />");
}

、

Ajax プログラミングに対する近視眼的で間違ったアプローチであることがわかります。スクリプトが認証を必要とし、リクエストで有効な証明書が提供されない場合、サーバーは 403 や 401 などのエラー コードを返します。ただし、サーバーがリクエストに応答したため、準備完了ステータスは 4 に設定されます (応答がリクエストの予期したものではなかったとしても)。最終的に、ユーザーは有効なデータを取得できなくなり、JavaScript が存在しないサーバー データを使用しようとすると重大なエラーが発生する可能性があります。

最小限の労力で、サーバーがリクエストを完了するだけでなく、「すべて良好」ステータス コードを返すことを確認できます。このコードは「200」で、XMLHttpRequest オブジェクトの status 属性を通じて報告されます。サーバーがリクエストを完了しただけでなく、OK ステータスを報告したことを確認するには、リスト 7 に示すように、コールバック関数に別のチェックを追加します。

リスト 7. 有効なステータス コードのチェック

function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var 応答 = request.responseText.split("|");
document.getElementById("order").value = 応答[0];
document.getElementById("アドレス").innerHTML =
response[1].replace(/n/g, "<br />");
} それ以外
alert("ステータスは " + request.status);
}

、

問題があるかどうかを確認でき、説明のないコンテキストから切り離されたデータで構成されるページがユーザーに表示されるだけでなく、役立つエラー メッセージがユーザーに表示されます。

リダイレクトと再ルーティング

エラーの詳細に入る前に、Ajax を使用するときに心配する必要のない問題、つまりリダイレクトについて説明する価値があります。 HTTP ステータス コードのうち、これは次のような 300 番台のステータス コードです。

301: Moved Permanently 302: Found (リクエストは別の URL/URI にリダイレクトされました)
·305: プロキシの使用 (リクエストは、要求されたリソースにアクセスするためにプロキシを使用する必要があります)

Ajax プログラマは、次の 2 つの理由により、リダイレクトの問題についてあまり心配していない可能性があります。

· まず、Ajax アプリケーションは、通常、特定のサーバー側向けに作成されるように設計されています。スクリプト、サーブレット、またはアプリケーション。 Ajax プログラマーは、ユーザーが見ることなく消えてしまうコンポーネントについてはあまり明確ではありません。そのため、場合によっては、リソースが移動したことがわかっていて (移動したため、または何らかの手段で移動したため)、リクエスト内の URL を変更すると、この結果が二度と表示されなくなります。
さらに重要な理由は、Ajax アプリケーションとリクエストがサンドボックスにカプセル化されていることです。これは、Ajax リクエストを生成する Web ページを提供するドメインが、それらのリクエストに応答するドメインである必要があることを意味します。したがって、ebay.com が提供する Web ページは、amazon.com で実行されているスクリプトに対して Ajax スタイルのリクエストを行うことはできません。また、ibm.com 上の Ajax アプリケーションは、netbeans.org で実行されているサーブレットに対してリクエストを行うことはできません。
·その結果、セキュリティ エラーが発生せずにリクエストを別のサーバーにリダイレクトすることはできません。このような場合、ステータス コードはまったく取得されません。通常、JavaScript エラーはデバッグ コンソールで生成されます。したがって、ステータス コードについて十分に考慮した後は、リダイレクト コードの問題を完全に無視できます。

その結果、セキュリティ エラーが発生せずにリクエストを別のサーバーにリダイレクトすることはできません。このような場合、ステータス コードはまったく取得されません。通常、JavaScript エラーはデバッグ コンソールで生成されます。したがって、ステータス コードについて十分に考慮した後は、リダイレクト コードの問題を完全に無視できます。

エラー

ステータス コード 200 を受け取って、300 シリーズのステータス コードはほとんど無視できることがわかったら、心配する必要がある唯一のコード セットは、さまざまな種類のエラーを示す 400 シリーズ コードです。リスト 7 に戻ると、エラーを処理するときに、いくつかの一般的なエラー メッセージのみがユーザーに出力されることがわかります。これは正しい方向への一歩ではありますが、これらのメッセージは、アプリケーションで作業しているユーザーやプログラマに正確に何が問題なのかを伝えるのにはまだあまり役に立ちません。

まず、見つからないページのサポートを追加します。実際、ほとんどの実運用システムではこのようなことは起こりませんが、テスト スクリプトの場所が変更されたり、プログラマが間違った URL を入力したりする場合は、珍しいことではありません。 404 エラーを自然に報告できれば、イライラしているユーザーやプログラマーにさらに多くの支援を提供できます。たとえば、サーバー上のスクリプトが削除された場合、リスト 7 のコードを使用すると、図 5 に示すような説明のないエラーがユーザーに表示されます。

エッジケースと困難な状況

この時点で、初心者プログラマーの中にはこれが何のことなのか疑問に思う人もいるかもしれません。ここで知っておくべき事実があります。2 や 3 などの準備完了状態や 403 などのステータス コードを使用する Ajax リクエストは 5% 未満です (実際には、この割合はおそらく 1% に近いか、それ以下です)。これらの状況は非常に重要であり、エッジ ケースと呼ばれます。これらは、最も珍しい問題が発生する非常に特殊な状況でのみ発生します。このような状況は一般的ではありませんが、これらの特殊なケースは、ほとんどのユーザーが遭遇する問題の 80% を占めています。

一般的なユーザーにとって、アプリケーションが 100 回正しく動作するという事実は通常忘れられますが、アプリケーションの 1 つの間違いははっきりと記憶されます。彼ら。エッジケース (または困難な状況) にうまく対処できれば、サイトに戻ってくるユーザーに満足のいく報酬を提供できます。

図 5. 一般的なエラー処理

ユーザーには、問題が認証の問題なのか、スクリプトが見つからないのか (今回の場合のように)、ユーザー エラーなのか、あるいはコード内の何かなのかを判断する方法がありません。簡単なコードを追加すると、このエラーをより具体的にすることができます。リスト 8 を参照してください。これは、スクリプトが見つからない場合や認証エラーが発生した場合の処理​​を担当しており、これらのエラーが発生した場合には特定のメッセージが表示されます。

リスト 8. 有効なステータス コードのチェック

function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var 応答 = request.responseText.split("|");
document.getElementById("order").value = 応答[0];
document.getElementById("アドレス").innerHTML =
response[1].replace(/n/g, "<br />");
else if (request.status == 404) {
アラート (「要求された URL が見つかりません。」);
else if (request.status == 403) {
alert("アクセスが拒否されました。");
} それ以外
alert("ステータスは " + request.status);
}

、

もう少し役立つ情報を提供します。図 6 は図 5 と同じエラーを示していますが、今回のエラー処理コードは、正確に何が起こったのかをユーザーまたはプログラマにわかりやすく説明します。

図 6. 特殊なエラー処理

私たち自身のアプリケーションでは、認証が失敗した場合にユーザー名とパスワードをクリアし、画面にエラー メッセージを追加することを検討するかもしれません。同様のアプローチを使用して、スクリプトが見つからない場合やその他の 400 タイプのエラーをより適切に処理できます (たとえば、405 は、HEAD リクエストの送信などの受け入れられないリクエスト メソッドが許可されていないことを意味し、407 はプロキシ認証が必要であることを意味します)。ただし、どのオプションを選択しても、サーバーから返されたステータス コードの処理を開始する必要があります。

その他のリクエスト タイプ

XMLHttpRequest オブジェクトを本当に制御したい場合は、HEAD リクエストをディレクティブに追加して、この最終機能を実装することを検討してください。前の 2 つの記事では、GET リクエストを生成する方法を紹介しました。次の記事では、POST リクエストを使用してサーバーにデータを送信する方法について説明します。ただし、エラー処理と情報収集の強化の観点から、HEAD リクエストを生成する方法を学習する必要があります。

リクエストの作成

HEAD リクエストの作成は実際には非常に簡単です。リスト 9 に示すように、最初のパラメーターとして (「GET」または「POST」ではなく) 「HEAD」を指定して open() メソッドを呼び出します。

リスト 9. Ajax を使用して HEAD リクエスト

関数を生成する getSalesData() {
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);

、

サーバーは GET または POST リクエストの場合のように実際の応答を返しません。代わりに、サーバーはリソースのヘッダーのみを返します。これには、応答内のコンテンツが最後に変更された時期、要求されたリソースが存在するかどうか、その他多くの有用な情報が含まれます。この情報を使用すると、サーバーによって処理されて返される前に、リソースについて知ることができます。

この種のリクエストに対して実行できる最も簡単な方法は、すべての応答ヘッダーの内容を単純に出力することです。これにより、HEAD リクエストを通じて何が利用できるかがわかります。リスト 10 は、HEAD リクエストから取得した応答ヘッダーの内容を出力する単純なコールバック関数を提供します。

関数 updatePage() {

から取得した応答ヘッダーの内容を出力します

if (request.readyState == 4) {
アラート(request.getAllResponseHeaders());
}

。

これは、サーバーに対して HEAD リクエストを行う単純な Ajax アプリケーションから返される応答ヘッダーを示しています。

これらのヘッダーを個別に (サーバー タイプからコンテンツ タイプまで) 使用して、Ajax アプリケーションに追加の情報や機能を提供できます。

URL の確認

URL が存在しない場合に 404 エラーを確認する方法を説明しました。これが一般的な問題であることが判明した場合 (おそらく特定のスクリプトまたはサーブレットが欠落している可能性があります)、完全な GET または POST リクエストを行う前に URL を確認することをお勧めします。この機能を実装するには、HEAD リクエストを生成し、コールバック関数で 404 エラーをチェックします。リスト 11 は、単純なコールバック関数を示しています。

リスト 11. URL が存在するかどうかを確認する

function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
alert("URL が存在します");
else if (request.status == 404) {
alert("URL が存在しません。");
} それ以外 {
alert("ステータスは次のとおりです: " + request.status);
}
}

言う

と、このコードの価値はそれほど大きくありません。サーバーはリクエストに応答し、Content-Length 応答ヘッダーを埋め込む応答を構築する必要があるため、処理時間は節約されません。さらに、リスト 7 に示すように、エラー コードを処理するだけではなく、GET または POST を使用してリクエストを生成するため、リクエストを生成し、HEAD リクエストを使用して URL が存在するかどうかを確認するのと同じくらい時間がかかります。ただし、現在利用可能なものを正確に知っておくと便利な場合もあります。創造性がいつ発揮されるか、いつ HEAD リクエストが必要になるかはわかりません。

便利な HEAD リクエスト

HEAD リクエストが非常に役立つ領域の 1 つは、コンテンツの長さまたはコンテンツのタイプを確認することです。これにより、リクエストを処理するために大量のデータを送り返す必要があるかどうか、またサーバーが HTML、テキスト、または XML の代わりにバイナリ データを返そうとしているかどうかを判断できます (3 種類のデータはすべて、JavaScript で処理する方が簡単です)。バイナリデータ）。

このような場合は、適切なヘッダー名を使用して、それを XMLHttpRequest オブジェクトの getResponseHeader() メソッドに渡すだけです。したがって、応答の長さを取得するには、request.getResponseHeader("Content-Length"); を呼び出すだけです。コンテンツ タイプを取得するには、request.getResponseHeader("Content-Type"); を使用します。

多くのアプリケーションでは、HEAD リクエストを生成しても機能は追加されず、リクエストが遅くなる可能性もあります (HEAD リクエストで応答に関するデータを取得し、実際に応答を取得するために GET または POST リクエストを使用することにより)。ただし、スクリプトやサーバー側コンポーネントが不明な場合は、HEAD リクエストを使用すると、実際に応答データを処理したり、応答の送信に多くの帯域幅を必要としたりせずに、基本的なデータを取得できます。

結論

多くの Ajax および Web プログラマにとって、この記事で紹介されている内容は高度すぎると思われるかもしれません。 HEAD リクエストを生成する価値は何ですか? JavaScript でリダイレクト ステータス コードを明示的に処理する必要があるのはどのような場合ですか?これらは単純なアプリケーションにとっては良い質問ですが、答えは、これらの高度な技術の価値はそれほど大きくないということです。

しかし、Web はもはや単純なアプリケーションを実装するだけで済む場所ではありません。ユーザーはより高度になり、顧客はより優れた安定性とより高度なエラー報告を期待しており、アプリケーションが 1% の確率でダウンしている場合、管理者は次のようなことを行う可能性があります。そのために解雇されます。

したがって、作業を単純なアプリケーションに限定することはできず、XMLHttpRequest をより深く理解する必要があります。

· さまざまな準備状態について考え、これらの準備状態がブラウザー間でどのように異なるかを理解できれば、アプリケーションをすぐにデバッグできます。準備状態に基づいてクリエイティブな機能を開発し、要求されたステータスをユーザーや顧客にレポートすることもできます。
·ステータス コードを制御したい場合は、スクリプト エラー、予期しない応答、およびエッジ ケースを処理するようにアプリケーションを設定できます。その結果、アプリケーションはすべてが正常な場合だけでなく、常に正しく動作します。
· HEAD リクエストを生成し、URL が存在するかどうかを確認し、ファイルが変更されているかどうかを確認する機能を追加して、ユーザーが有効なページを取得できるようにし、ユーザーに表示される情報が最新のものであることを確認します (最も重要なこと)。このアプリがどれほど堅牢で多用途であるか。
この記事の目的は、アプリケーションを派手に見せることではなく、黄色のスポットライトを削除してテキストの美しさを強調したり、デスクトップに近づけたりすることです。これらはすべて Ajax の機能 (次のいくつかの記事で説明します) ですが、ケーキの上のクリームの層のようなものです。 Ajax を使用してアプリケーションがエラーや問題を適切に処理できる強固な基盤を構築できれば、ユーザーはサイトやアプリケーションに戻ってくるでしょう。次回の記事では、顧客を興奮させてしまう直感的なテクニックを追加します。 (次の記事をお見逃しなく!)