一次简单的 Http 请求异常处理 (请求的 url 太长, Nginx 直接返回 400, 导致请求服务异常)

1 结论

按照惯例直接说结论。

后台服务 A 有一个 Http 接口, 代码如下:

@RequestMapping(value = "/user", method = RequestMethod.GET)
public List<UserInfoVo> getUserInfoByUserIds(@RequestParam(value = "userIds") List<String> userIds) {// ...
}

没错, 一个 Get 请求, 入参是一个 List。

同时有另一个后台服务 B, 里面有段逻辑会通过 RestTemplate 调用服务 A 的这个接口, 代码如下:

public List<UserInfoVo> batchGetUserInfo(Collection<String> userIds) {String url = String.format("%s/user?userIds=%s", remoteHost, StringUtils.join(userIds, ","));String returnResult = restTemplate.getForObject(url, String.class);// ...
}

在服务 B 中, 通过 batchGetUserInfo 方法请求服务 A 时, 传入了一个长度为 122 的 List, List 中每一项是一个 32 位的 UUID。
结果导致调用服务 A 的 url 长度太长, Nginx 认为这时一个异常的请求格式, 直接返回状态码 400, 结构导致服务 B 逻辑异常。

2 过程

2.1 反馈

下午, 突然收到用户反馈: 进入某个页面后, 直接白屏。

2.2 定位到直接原因

直接通过 Nginx 请求日志, 发现用户反馈的操作时间段内, 有一个接口一直返回 400 的错误。
根据客户端反馈这个错误的确会导致页面白屏。

知道了直接原因了, 但是没有解决, 还是需要定位到根本原因。

2.3 Arthas 排查

通过错误的 url, 定位到对应的代码, 然后通过 Kibana 查看日志, 发现只有一个简单的异常提示, 没输出任何堆栈信息。

因为是一个查询接口, 所以本地通过拼接参数, 尝试请求这个接口, 发现是逻辑正常的, 应该是数据问题, 这就尴尬了。

通过分析代码逻辑, 看不出什么异常的。
在没有日志, 复现不出反馈情况, 代码逻辑分析不出异常时, 决定通过 Arthas 协助排查了。

在生产环境中, 启动了一个预发版本, 通过 url 模拟用户请求。

同时启动 Arthas, watch 对应的接口

watch com.aaa.bbb.TestController testMethod "{params,returnObj,throwExp}" -x 4

定位到以下异常:

org.springframework.web.client.HttpClientErrorException: 400 at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:91) ~[spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:700) ~[spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:653) ~[spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:613) ~[spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]at org.springframework.web.client.RestTemplate.getForObject(RestTemplate.java:287) ~[spring-web-4.3.7.RELEASE.jar:4.3.7.RELEASE]at com.aaa.bbb..service.impl.RemoteServiceImpl.batchGetUserInfo(RemoteServiceImpl.java:206) ~[classes/:?]......

根据堆栈信息定位到代码

public List<StudentVo> batchGetUserInfo(Collection<String> userIds) {String url = String.format("%s/user?userIds=%s", remoteHost, StringUtils.join(userIds, ","));String returnResult = restTemplate.getForObject(url, String.class);// ...
}

看逻辑没多大的异常, 唯一比较惊讶的就是 Get 请求, 入参确实是一个 List, 不过 Http 本身就支持这样操作。

继续通过 Arthas, watch 对应的接口, 不过这次 watch 上面的代码:

watch com.aaa.bbb..service.impl.RemoteServiceImpl batchGetUserInfo "{params,returnObj,throwExp}" -x 4

继续通过 url 模拟用户请求。

发现堆栈信息同样的 HttpClientErrorException: 400 异常, 但是通过打印的参数列表发现, 入参竟然是 123 个的 String。

第一时间感觉到: 参数太多, 拼接的 url 太长, 导致请求失败。
但是转念一下, Get 请求 url 的长度限制是浏览器的行为, Http 协议没有对传输的数据大小进行限制。
现在是 2 个后台服务的 Http 请求, 没有经过任什么浏览器, 理论上是这个长度无限制的。

2.4 Nginx 直接返回 400 错误码

请求 url 感觉没什么问题?
既然这样, 会不会是结果响应方处理有什么异常吗?

同样通过 Kibana 查看日志, 发现对应的接口, 没有当前用户的请求日志。也就是说, 对应的请求没有到达服务 A。

不是被调用方的问题, 那么会不会是 RestTemplate 这个框架内部做了限制呢?

从 restTemplate.getForObject 出发, 进入到源码, 发现内部也是没有对 url 长度做限制的, 同时定位到抛出异常的位置如下

public class DefaultResponseErrorHandler implements ResponseErrorHandler {@Overridepublic void handleError(ClientHttpResponse response) throws IOException {// 从响应里面获取到状态码HttpStatus statusCode = getHttpStatusCode(response);switch (statusCode.series()) {// 状态码 4xxcase CLIENT_ERROR:throw new HttpClientErrorException(statusCode, response.getStatusText(),response.getHeaders(), getResponseBody(response), getCharset(response));// 状态码 5xx						case SERVER_ERROR:throw new HttpServerErrorException(statusCode, response.getStatusText(), response.getHeaders(), getResponseBody(response), getCharset(response));default:throw new RestClientException("Unknown status code [" + statusCode + "]");}}
}

抛出异常的结果是根据请求返回的状态码来决定的。 也就是服务 B 有发起请求, 同时收到了一个 400 的错误码, restTemplate 将其封装为一个 HttpClientErrorException。

调用方有发起请求, 被调用方没有请求日志, 2 者之间通过通过 Http 请求, 那么有问题的的地方应该就是 2 者中间的 Nginx 了。

2.5 验证

public List<StudentVo> batchGetUserInfo(Collection<String> userIds) {String url = String.format("%s/user?userIds=%s", remoteHost, StringUtils.join(userIds, ","));String returnResult = restTemplate.getForObject(url, String.class);// ...
}

将上面的 remoteHost 替换为一个具体的 ip 地址, 直接请求对应的容器, 绕过 Nginx。
重新部署, 通过 url 模拟用户请求, 正常响应。

3 总结

服务 A 的请求先经过 Nginx, 再由 Nginx 转发到 B。
而异常的用户的请求到了 Nginx, Nginx 直接返回了 400, 从而导致用户请求异常。

通过查询资料, Nginx 报 400 的场景如下

1. request_uri 过长超过 nginx 配置大小
2. cookie 或者 header 过大超过 nginx 配置大小
3. 空 HOST 头
4. content_length 和 body 长度不一致

我遇到的情况就是第一种。
Nginx 处理时认为客户端请求格式错误, 于是直接返回 400, 不会向 upstream server (也就是下游服务) 转发请求, 因而 upstream server 对这些错误请求其实完全是无感知的。

至此结束。

碎碎念:
其实对 Http 响应码有一点了解, 结合上面获取到的请求参数太多和堆栈的信息的 400, 基本可以推导出问题了, 不用像我一样, 一步步猜测验证。
而本身通过这次, 对 Http 的响应码和 Nginx 也算是多了一点了解。