自動検出のエラー メッセージを処理する
自動検出の各種エラーと、そのエラーの対処法について説明します。
自動検出により、カスタムのアプリケーションは構成情報を自動的に取得できるようになり、最適に動作するようになります。 ただし、物事は計画どおりに進まないこともあります。 発生することがある一般的なエラーについて説明して、ユーザーに要求するクライアントの手動構成を最小限にするためのエラー処理の方法について説明します。
HTTP 状態のエラー
最初の種類のエラーは、自動検出の要求を送信するときに発生することがある HTTP 状態です。 応答に含まれる HTTP 状態が 200 (OK) 以外の場合、求めている自動検出の応答は応答のペイロードに含まれていません。 わかりやすくするために、200 以外の状態コードを 3 つのカテゴリに分類します。
表 1. HTTP 状態コード
| ステータス コード | エラーの種類 | 処理方法 |
|---|---|---|
| 301 または 302 |
リダイレクト エラー |
HTTP 応答ヘッダーの "Location" に格納されている URI に向けて要求を再送信します。 詳細については、「リダイレクト エラーの処理」を参照してください。 |
| 401 |
未認証エラー |
自動検出プロセスでは、複数の潜在的な URL を試してみることが必要になるため、このエラーはある URL のみで発生することがあります (その次の URL は資格情報を受け入れた状態になります)。 このため、単一の 401 エラーで資格情報が無効だと見なしてはいけません。 ただし、複数の URL から 401 エラーを受け取る場合は、ユーザーにパスワードの再入力を求めるプロンプトを表示します (可能な場合)。 |
| その他の 200 以外の状態 |
無効な自動検出エンドポイントのエラー |
200 以外の状態コードを返す URL は無効であると見なして、一覧内で次に当たる URL の試行を続行します。 |
自動検出のエラー
自動検出要求の送信後に 200 (OK) の状態コードを得たとしても、必要としている情報がサーバーから送られたという意味にはなりません。 200 の状態は自動検出の応答があったということだけを意味し、その応答のペイロードにはエラーが含まれていることもあります。 SOAP 形式と POX 形式では、エラー情報の場所が異なります。
SOAP 自動検出のエラー
SOAP 自動検出の場合は、1 つ以上の ErrorCode (SOAP) 要素が応答の異なる場所に含まれていることがあります。 一般に、Response (SOAP) 要素の子要素として期待することや、応答内の各 UserResponse (SOAP) 要素の子として期待することができます。 また、UserSettingError (SOAP) 要素の子として出現することもあります (存在する場合)。 エラーのコンテキストは、次に示すように ErrorCode 要素の場所によって変化します。
Response 要素の子要素の場合、ErrorCode 要素は要求全体に当てはまるエラーを表します。
UserResponse 要素の子の場合は、特定のユーザーにのみ当てはまるエラーを表します。
UserSettingError 要素の子の場合は、要求された特定の設定に当てはまるエラーを表します。
応答の例を調べてみましょう。 この例では、Response 要素の ErrorCode 要素に "NoError" という値が含まれています。この値は、全体的な成功を表します。 ただし、UserResponse 要素の ErrorCode 要素には "RedirectAddress" という値が含まれています。この値は、その特定のユーザーにエラーが発生したことを表します。
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="https://schemas.xmlsoap.org/soap/envelope/"
xmlns:a="http://www.w3.org/2005/08/addressing">
<s:Header>
<a:Action s:mustUnderstand="1">https://schemas.microsoft.com/exchange/2010/Autodiscover/Autodiscover/GetUserSettingsResponse</a:Action>
<h:ServerVersionInfo xmlns:h="https://schemas.microsoft.com/exchange/2010/Autodiscover"
xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<h:MajorVersion>14</h:MajorVersion>
<h:MinorVersion>3</h:MinorVersion>
<h:MajorBuildNumber>136</h:MajorBuildNumber>
<h:MinorBuildNumber>1</h:MinorBuildNumber>
<h:Version>Exchange2010_SP2</h:Version>
</h:ServerVersionInfo>
</s:Header>
<s:Body>
<GetUserSettingsResponseMessage xmlns="https://schemas.microsoft.com/exchange/2010/Autodiscover">
<Response xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ErrorCode>NoError</ErrorCode>
<ErrorMessage />
<UserResponses>
<UserResponse>
<ErrorCode>RedirectAddress</ErrorCode>
<ErrorMessage>Redirection address.</ErrorMessage>
<RedirectTarget>elvin@mail.contoso.com</RedirectTarget>
<UserSettingErrors />
<UserSettings />
</UserResponse>
</UserResponses>
</Response>
</GetUserSettingsResponseMessage>
</s:Body>
</s:Envelope>
「ErrorCode (SOAP)」の記事に、発生することがあるすべてのエラーの一覧が記載されています。 これらのほとんどは、回復不可能なエラーを表しますが、いくつかは特別な処理を認めるものがあります。
表 2. SOAP 自動検出の ErrorCode の値
| ErrorCode の値 | 処理方法 |
|---|---|
| RedirectAddress |
RedirectTarget (SOAP) 要素の電子メール アドレスを使用して、新しい電子メール アドレスで自動検出を再開します。 |
| RedirectUrl |
RedirectTarget 要素の URL を新しい URL として要求を再送信します。 |
| ServerBusy |
少し間をおいて、この URL を再試行します。 一定時間待機するか、この URL を単に試行する URL の一覧の最後に移動します。 このエラーを 1 つの URL から複数回受け取る場合は、その URL が無効であると見なす必要があります。 |
POX 自動検出のエラー
POX 自動検出サービスは、少し異なる方法でエラーを報告します。 回復不可能なエラーは、Error (POX) 要素に含まれています。 「ErrorCode (POX)」の記事に、発生することがあるすべてのエラーの一覧が記載されています。
リダイレクトのエラーは、Action (POX) 要素に含まれています。 Action 要素の "settings" 以外の値は、どれもリダイレクト エラーを表します。
表 3. POX 自動検出の ErrorCode の値
| Action の値 | 処理方法 |
|---|---|
| redirectAddr |
RedirectAddr (POX) 要素の電子メール アドレスを使用して、新しい電子メール アドレスで自動検出を再開します。 |
| redirectUrl |
RedirectUrl (POX) 要素の URL を新しい URL として要求を再送信します。 |
この例では、Action 要素には "redirectAddr" という値が含まれています。この値は、RedirectAddr 要素に含まれた新しい電子メール アドレスで新しい要求を送信する必要があることを示しています。
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<Account>
<Action>redirectAddr</Action>
<RedirectAddr>elvin@mail.contoso.com</RedirectAddr>
</Account>
</Response>
</Autodiscover>
リダイレクト エラーの処理
リダイレクト エラーのシナリオは 2 つの方法で処理できます。
新しい電子メール アドレスで自動検出を再開する。
新しい URL に要求を再送信する。
どちらのシナリオも続行する前に何らかの検証が必要になります。
新しい電子メール アドレスで自動検出を再開する
自動検出リダイレクト応答で新しいメール アドレスを取得する場合は、まず、リダイレクト エラー応答で指定された新しいメール アドレスが、エラーの発生した要求で送信したアドレスと同じアドレスではないことを確認します。 その場合は、自動検出を再起動しないでください。代わりに、応答を生成した URL が無効であると考えてください。
新しい電子メール アドレスが異なる場合は、潜在的な自動検出エンドポイント URL の既存の一覧を破棄して、新しい電子メール アドレスに基づいた新しい一覧を生成します。
新しい URL に要求を再送信する
自動検出リダイレクト応答で新しい URL を取得したときには、まず、その URL を次のようにして検証する必要があります。
URL が HTTPS URL であることを確認します。
これまでに現在の電子メール アドレスで、この URL からエラーを受け取っていないことを確認します。
カスタム アプリケーションに適用可能な場合は、ユーザーにリダイレクトについて知らせて、リダイレクトに従う許可を取ります。
URL に要求を送信して、サーバーが提示した SSL 証明書が有効であることを確認します。
URL が検証に合格した場合は、この新しい URL に要求を再送信します。
関連項目
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示