您正在查看的是 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
标头,就会出现此错误。
根据
RFC 7231 规范第 6.5.5 节:405 不允许的方法,源服务器必须在 405
响应中生成并发送 Allow
标头字段,该响应包含目标资源当前支持的方法列表。否则,Apigee 会返回 502 Bad Gateway
和错误代码 protocol.http.Response405WithoutAllowHeader
。
原因 | 说明 | 适用的问题排查说明 |
---|---|---|
不含来自后端服务器的“Allow”标头的 405 响应 | 处理 API 请求的后端服务器会返回 405 状态代码(不含 Allow 标头)。 |
Edge 公有云和私有云用户 |
常见诊断步骤
使用以下工具/技巧之一来诊断此错误:
API 监控
要使用 API Monitoring 诊断错误,请执行以下操作:
- 以拥有 适当角色的用户身份登录 Edge 界面。
切换到您要调查问题的组织。
- 前往 Analyze > API Monitoring > Investigate 页面。
- 选择您发现错误的具体时间范围。
根据时间绘制故障代码。
选择具有错误代码
protocol.http.Response405WithoutAllowHeader
的单元格,如下所示:错误代码
protocol.http.Response405WithoutAllowHeader
的相关信息如下所示:点击查看日志 ,然后展开其中一个失败的请求以查看更多信息。
- 在日志窗口中,请注意以下详细信息:
- 状态代码:
502
- 错误来源:
target
- 错误代码:
protocol.http.Response405WithoutAllowHeader
。
- 状态代码:
- 如果故障来源为
target
且故障代码为protocol.http.Response405WithoutAllowHeader
,则表示后端服务器返回了405 Method Not Allowed
状态代码,但没有Allow
标头。
跟踪工具
如需使用跟踪工具诊断错误,请执行以下操作:
- 启用
跟踪会话,并且
- 等待
502 Bad Gateway
错误发生,或者 - 如果您可以重现问题,请进行 API 调用以重现问题 -
502 Bad Gateway
错误
- 等待
确保已启用 Show all FlowInfos:
- 选择其中一个失败的请求并检查跟踪记录。
- 浏览跟踪记录的不同阶段,并找到失败的位置。
通常情况下,您会在请求发送到目标服务器阶段之后的流程中发现此错误,如下所示:
记下跟踪记录中的错误值。
上面的示例轨迹将错误显示为
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
,这表明导致此错误的原因在于后端发送的405
响应状态代码没有Allow
标头。响应标头 值 X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
X-Apigee-fault-source target
NGINX
如需使用 NGINX 访问日志诊断错误,请执行以下操作:
- 如果您是 Private Cloud 用户,则可以使用 NGINX 访问日志来确定有关 HTTP
502
错误的关键信息。 检查 NGINX 访问日志:
/opt/apigee/var/log/edge-router/nginx/ORG~ORG.PORT#_access_log
其中:将 ORG、ORG 和 PORT# 替换为实际值。
- 搜索以查看在特定持续时间内是否存在任何错误代码为
protocol.http.Response405WithoutAllowHeader
的502
错误(如果问题发生在过去),或者是否有任何请求仍然失败并显示502
。 如果您确实发现任何
502
错误,且 X-Apigee-fault-code 与protocol.http.Response405WithoutAllowHeader
的值匹配,请确定 X-Apigee-fault-code 的值。NGINX 访问日志中的 502 错误示例:
NGINX 访问日志中的上述示例条目具有 X-Apigee-fault-code 和 X-Apigee-fault-source 的以下值:
响应标头 值 X-Apigee-fault-code protocol.http.Response405WithoutAllowHeader
X-Apigee-fault-source target
原因:405 响应没有来自后端服务器的“Allow”标头
诊断
- 按照常见诊断步骤中的说明,使用 API Monitoring、Trace Tool 或 NGINX 访问日志确定
502 Bad Gateway
的故障代码和故障来源。 - 如果故障代码为
protocol.http.Response405WithoutAllowHeader
且故障来源的值为target
,则表示后端服务器返回了405
状态代码(不含Allow
标头)。因此,Apigee 会返回502 Bad Gateway
并返回错误代码protocol.http.Response405WithoutAllowHeader
。
分辨率
请使用下列方法之一解决此问题:
后端服务器
方法 1:修复后端服务器,以发送带有允许标头的 405 状态代码:
确保后端服务器始终遵循 RFC 7231 第 6.5.5 节:405 不允许的方法规范,并通过在
Allow
标头中添加允许的方法列表来发送405
状态代码,如下所示:Allow: HTTP_METHODS
- 例如,如果您的后端服务器允许使用
GET
、POST
和HEAD
方法,则需要确保Allow
标头包含这些方法,如下所示:Allow: GET, POST, HEAD
故障处理
方法 2:使用故障处理功能从 API 代理发送包含“Allow”标头的 405 状态代码:
如果后端服务器返回的 405
状态代码没有 Allow
标头,您可以使用故障处理功能以来自 API 代理的 405
状态代码和 Allow
标头进行响应,如下所示:
创建一项政策(如 assignMessage 政策或 RaiseFault 政策),然后将状态代码设置为
405
,其中包含Allow
标头和一条自定义消息。发送带有“Allow”标头的 405 消息的 AssignmentMessage 政策示例:
<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 调用,并验证您是否收到带有
Allow
标头的405
状态代码。
配置媒体资源
方法 3:在消息处理器中配置属性,以防止 Apigee Edge 返回 502 错误
- 如果您是 私有云用户,则可以将属性
HTTP.ignore.allow_header.for.405
更新为true
,以防止 Apigee Edge 引发502
错误,即使后端服务器返回不含Allow
标头的405
状态代码响应也是如此,具体操作指南如下: 在消息处理器中为 405 属性配置忽略允许标头。 - 如果您是 公有云用户 ,请联系 Apigee Edge 支持团队
规范
根据以下规范,Apigee 要求后端服务器返回 405 Method Not Allowed
响应以及 Allow
标头:
规范 | |
---|---|
RFC 7231,第 6.5.5 节:405 方法不允许 | |
RFC 7231,第 7.4.1 节:允许 |
需要注意的要点
推荐的解决方案是修复后端服务器,以发送带有 Allow
标头的 405
状态代码,并遵循
RFC 7231 第 6.5.5 节:405 不允许的方法规范。
如果您仍然需要 Apigee 支持部门的任何帮助,请参阅 必须收集诊断信息。
必须收集的诊断信息
如果按照上述说明操作后,问题仍然存在,请收集以下诊断信息,然后联系 Apigee Edge 支持团队。
如果您是公有云用户,请提供以下信息:
- 组织名称
- 环境名称
- API 代理名称
- 完成用于重现
502 Bad Gateway
的curl
命令,并提供错误代码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