<ph type="x-smartling-placeholder"></ph>
  您正在查看 Apigee Edge 文档。
  转到
     Apigee X 文档。 信息
问题
    客户端应用收到包含错误的 HTTP 状态代码 502 Bad Gateway
    代码 protocol.http.Response405WithoutAllowHeader 作为 API 调用的响应。
  
错误消息
客户端应用将获得以下响应代码:
HTTP/1.1 502 Bad Gateway
此外,您可能还会看到以下错误消息:
{
   "fault":{
      "faultstring":"Received 405 Response without Allow Header",
      "detail":{
         "errorcode":"protocol.http.Response405WithoutAllowHeader"
      }
   }
}可能的原因
    如果后端服务器返回 405 Method Not Allowed 状态,就会发生此错误
    不含 Allow 标头的代码。
  
    根据规范
    <ph type="x-smartling-placeholder"></ph>
    RFC 7231 第 6.5.5 节:405 Method Not Allowed 部分,则源服务器应
    必须在 405 响应中生成并发送 Allow 标头字段,其中包含
    目标资源当前支持的方法列表。否则,Apigee 会做出如下回应:
    502 Bad Gateway 和错误代码 protocol.http.Response405WithoutAllowHeader。
| 原因 | 说明 | 适用的问题排查说明 | 
|---|---|---|
| 405 响应,不含来自后端服务器的“Allow”标头 | 正在处理 API 请求的后端服务器会返回 405状态代码,但不含Allow标头。 | Edge 公有云和私有云用户 | 
常见诊断步骤
使用以下工具/技术之一来诊断此错误:
API 监控
<ph type="x-smartling-placeholder">如需使用 API Monitoring 诊断错误,请执行以下操作:
- 使用 适当的角色。
- 切换到您要在其中调查问题的单位。   
- 导航至分析 >API 监控 >调查页面。
- 选择您观察到错误的具体时间范围。
- 根据时间绘制错误代码。 <ph type="x-smartling-placeholder">
- 选择包含错误代码的单元格 - protocol.http.Response405WithoutAllowHeader,如下所示:  
- 有关错误代码 - protocol.http.Response405WithoutAllowHeader的信息 如下所示:  
- 点击查看日志 并展开某个失败的请求以查看更多信息。   
- 在日志窗口中,请注意以下详细信息:
      <ph type="x-smartling-placeholder">- </ph>
        
- 状态代码:502
- 故障来源:target
- 错误代码:protocol.http.Response405WithoutAllowHeader。
 
- 状态代码:
- 如果故障来源为 target且错误代码为protocol.http.Response405WithoutAllowHeader,则表示后端 服务器响应了405 Method Not Allowed状态代码,但不包含Allow标头。
跟踪工具
<ph type="x-smartling-placeholder">如需使用跟踪工具诊断错误,请执行以下操作:
- 启用 
      跟踪会话,以及
      <ph type="x-smartling-placeholder">- </ph>
        
- 等待发生 502 Bad Gateway错误,或者
- 如果您可以重现问题,请进行 API 调用以重现问题。
         502 Bad Gateway个错误
 
- 等待发生 
- 确保已启用 Show all FlowInfos:   
- 选择其中一个失败请求并检查跟踪记录。
- 浏览跟踪记录的不同阶段,并找到失败的位置。
- 该错误通常在 Request sent to target server(发送到目标服务器)之后的流中显示。 阶段,如下所示:   
- 请记下跟踪记录中的错误值。 - 上面的示例跟踪记录将错误显示为 - Received 405 Response without Allow Header。由于错误是在请求发送到后端后由 Apigee 引发的 服务器,则表示后端服务器发送了- 405响应状态代码 没有- Allow标头。
- 进入跟踪记录中的 AX(记录的 Google Analytics 数据)阶段,然后点击该阶段。
- 向下滚动到 Phase Details 中的 Error / Response Headers 部分 面板并确定 X-Apigee-fault-code 和 X-Apigee-fault-source 的值,如下所示:   
- 您将看到 X-Apigee-fault-code 和 X-Apigee-fault-source 的值显示为
      protocol.http.Response405WithoutAllowHeader和target指示此错误是因为后端发送了 不带Allow标头的405响应状态代码。响应标头 值 X-Apigee-fault-code protocol.http.Response405WithoutAllowHeaderX-Apigee-fault-source target
NGINX
<ph type="x-smartling-placeholder">如需使用 NGINX 访问日志诊断错误,请执行以下操作:
- 如果您是私有云用户,则可以使用 NGINX 访问日志来确定
      有关 HTTP 502错误的关键信息。
- 查看 NGINX 访问日志: - /opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log - 其中:ORG、ORG 和 PORT# 替换为实际值。 
- 搜索是否存在任何带有错误代码的 502错误protocol.http.Response405WithoutAllowHeader(如果 过去出现的问题),或者是否有任何请求仍以失败告终,502。
- 如果您发现任何 - 502错误并且 X-Apigee-fault-code 与 值- protocol.http.Response405WithoutAllowHeader,然后确定 X-Apigee-fault-source.- NGINX 访问日志中的 502 错误示例:   - 以上 NGINX 访问日志中的示例条目包含 X-Apigee- fault-code 和 X-Apigee-fault-source: - 响应标头 - 值 - X-Apigee-fault-code - protocol.http.Response405WithoutAllowHeader- X-Apigee-fault-source - target
原因:没有来自后端服务器的“Allow”标头的 405 响应
诊断
- 确定 502 Bad Gateway的错误代码和错误来源 使用 API 监控、跟踪工具或 NGINX 访问日志,具体说明请参见 常见的诊断步骤。
- 如果错误代码为 protocol.http.Response405WithoutAllowHeader,并且 故障来源的值为target,则表示后端服务器已 返回了405状态代码(不含Allow标头)。因此, Apigee 返回502 Bad Gateway并返回错误代码protocol.http.Response405WithoutAllowHeader。
分辨率
请使用下列方法之一解决此问题:
后端服务器
方法 1:修复后端服务器,以发送带有“Allow”标头的 405 状态代码:
<ph type="x-smartling-placeholder">- 确保后端服务器始终遵循规范 <ph type="x-smartling-placeholder"></ph> RFC 7231,第 6.5.5 节:405 Method Not Allowed,并以 - 405状态发送 方法是在- Allow标头中添加允许的方法列表 如下所示:- Allow: HTTP_METHODS 
- 例如,如果您的后端服务器允许 GET、POST和HEAD方法,则需要确保Allow标头包含 如下所示:Allow: GET, POST, HEAD 
故障处理
方法 2:使用故障处理功能,通过 API 中的“Allow”标头发送 405 状态代码 代理:
<ph type="x-smartling-placeholder">
    如果后端服务器返回 405 状态代码,但没有 Allow
    标头,您可以使用故障处理功能使用 405 状态代码和
    Allow 标头,如下所示:
  
- 创建政策,如 AssignMessage 政策 或 RaiseFault 政策 并将状态代码设置为 - 405,并采用- Allow标头和自定义 消息。- 使用“Allow”标头发送 405 错误的 AssignMessage 政策示例: - <AssignMessage async="false" continueOnError="false" enabled="true" name="AM-405WithAllowHeader"> <DisplayName>AM-405WithAllowHeader</DisplayName> <Set> <Payload contentType="application/json">{"Specified method is not allowed. Please use one of the methods mentioned in the Allow header."}</Payload> <StatusCode>405</StatusCode> <ReasonPhrase>Method Not Allowed</ReasonPhrase> </Set> <Add> <Headers> <Header name="Allow">GET, POST, HEAD</Header> </Headers> </Add> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage> 
- 在 - TargetEndpoint中创建- FaultRule,以调用政策 收到包含错误代码的- 502错误时- protocol.http.Response405WithoutAllowHeader。- 显示 FaultRule 的 TargetEndpoint 配置示例: - <TargetEndpoint name="default"> ... <FaultRules> <FaultRule name="405WithoutAllowHeader"> <Step> <Name>AM-405WithAllowHeader</Name> </Step> <Condition>(fault.name = "Response405WithoutAllowHeader")</Condition> </FaultRule> </FaultRules>
- 将这些更改保存到 API 代理的新修订版本中,然后部署该修订版本。
- 进行 API 调用并验证您是否收到了 405状态代码以及Allow标头。
配置媒体资源
方法 3:在消息处理器中配置属性,以防止 Apigee Edge 返回 502 错误
- 如果您是 私有云用户,则可以更新属性
      HTTP.ignore.allow_header.for.405到true,以防止 Apigee Edge 即使后端服务器返回405,也会引发502错误 状态代码(不含Allow标头)中: 为消息处理器中的 405 属性配置 ignore allow 标头。
- 如果您是 公有云用户 ,请与 Apigee Edge 支持团队联系
规范
    Apigee 期望后端服务器收到 405 Method Not Allowed 响应,以及
    并将 Allow 标头替换为以下规范:
  
| 规范 | |
|---|---|
| <ph type="x-smartling-placeholder"></ph> RFC 7231,第 6.5.5 节:405 Method Not Allowed | |
| <ph type="x-smartling-placeholder"></ph> RFC 7231,第 7.4.1 节:允许 | 
需要注意的要点
    建议的解决方案是修复后端服务器以发送 405 状态代码
    带有 Allow 标头,且符合规范
    <ph type="x-smartling-placeholder"></ph>
      RFC 7231,第 6.5.5 节:405 Method Not Allowed。
  
如果您仍然需要 Apigee 支持团队的任何帮助,请转到 必须收集诊断信息。
必须收集的诊断信息
按照上述说明操作后,如果问题依然存在,请收集以下内容 然后联系 Apigee Edge 支持团队。
如果您是公有云用户,请提供以下信息:
- 组织名称
- 环境名称
- API 代理名称
- 使用完整的 curl命令重现502 Bad Gateway错误代码protocol.http.Response405WithoutAllowHeader
- API 请求的跟踪文件
如果您是 Private Cloud 用户,请提供以下信息:
- 观察到失败请求的完整错误消息
- 环境名称
- API 代理软件包
- API 请求的跟踪文件
- NGINX 访问日志 - /opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log - 其中:ORG、ORG 和 PORT# 替换为实际值。 
- 消息处理器系统日志
/opt/apigee/var/log/edge-message-processor/logs/system.log