处理自动发现错误消息

项目
03/29/2023

了解不同类型的自动发现错误及其操作方法。

自动发现使应用程序能够自动检索配置信息，并且效果很好。但是，事情并不总是按计划进行。让我们看看可能发生的常见错误，以及如何处理它们，以尽量减少提示用户手动配置客户端的需要。

HTTP 状态错误

发送自动发现请求时可能会遇到的第一种类型的错误是 HTTP 状态。如果响应中的 HTTP 状态不是 200 (正常) ，则响应有效负载不包含要查找的自动发现响应。为简单起见，我们可以将非 200 状态代码分为三个类别。

表 1. HTTP 状态代码

状态代码	错误类型	要处理...
301 或 302	重定向错误	将请求重新发送到包含在“位置”HTTP 响应标头中的 URI。有关详细信息，请参阅处理重定向错误。
401	未经授权的错误	由于自动发现过程涉及尝试多个潜在 URL，因此可以在一个 URL 上获取此 URL，但只能让下一个 URL 接受凭据。因此，不应考虑单个 401 错误来指示凭据无效。但是，如果收到来自多个 URL 的 401 错误，则可能需要提示用户 (重新输入其密码（如果可能) ）。
任何其他非 200 状态	无效的自动发现终结点错误	请考虑返回任何其他非 200 状态代码的 URL 无效，并继续尝试列表中的下一个 URL。

自动发现错误

即使发送自动发现请求后收到 200 (正常) 状态代码，这并不意味着服务器发送了所需的信息。 200 状态仅表示你有一个自动发现响应，并且该响应可能包含有效负载中的错误。错误信息的位置因格式是 SOAP 还是 POX 而异。

SOAP 自动发现错误

对于 SOAP 自动发现，响应可以在不同位置包含一个或多个 ErrorCode (SOAP) 元素。通常，可以将一个作为响应 (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 Autodisover ErrorCode 值

ErrorCode 值	要处理...
RedirectAddress	使用 RedirectTarget (SOAP) 元素中电子邮件地址的新电子邮件地址重启自动发现。
RedirectUrl	将请求重新发送到RedirectTarget 元素中的 URL 的新 URL。
ServerBusy	在稍有延迟后重试此 URL。可以等待一定时间，或者直接将此 URL 移到 URL 列表的末尾以尝试。如果多次从 URL 收到此错误，则应将 URL 视为无效。

POX 自动发现错误

POX 自动发现服务报告错误的情况略有不同。不可恢复的错误包含在错误 (POX) 元素中。 ErrorCode (POX) 一文包含可能错误代码的完整列表。

重定向错误包含在 Action (POX) 元素中。除“settings”以外的 Action 元素的任何值都表示重定向错误。

表 3. POX Autodisover ErrorCode 值

操作值	要处理...
redirectAddr	使用重定向Addr (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>

处理重定向错误

可以通过两种方式处理重定向错误方案：

使用新电子邮件地址重启自动发现。
通过将请求重新发送到新 URL。

这两种方案都需要在继续之前进行一些验证。

使用新电子邮件地址重启自动发现

在自动发现重定向响应中收到新电子邮件地址时，请首先验证重定向错误响应中提供的新电子邮件地址是否与在导致错误的请求中发送的地址不同。如果是，则不应重启自动发现，而是将生成响应的 URL 视为无效。

如果新电子邮件地址不同，请放弃现有的潜在自动发现终结点 URL 列表，并基于新电子邮件地址生成新列表。

将请求重新发送到新 URL

在自动发现重定向响应中获取新 URL 时，应首先验证该 URL，如下所示：

验证 URL 是否为 HTTPS URL。
验证之前是否未收到来自此 URL 的当前电子邮件地址的错误。
如果适用于应用程序，请通知用户重定向并获取其跟踪重定向的权限。
向 URL 发送请求，并验证服务器提供的 SSL 证书是否有效。

如果 URL 通过验证，请将请求重新发送到此新 URL。

通过