HttpRequest.getBody().string() 只可以被读一次？

[hstan92]

类似于 #469

用着 v2.1.12 版本

我发现 HttpRequest.getBody().string() 好像只可以被读一次，想问这是原本的设计还是 bug 呢？

假设我有一个 Interceptor 里头 call 了 body.string()

@Interceptor
public class LoggerInterceptor implements HandlerInterceptor {
    private static final String TAG = "w_interceptor";

    @Override
    public boolean onIntercept(@NonNull HttpRequest request, @NonNull HttpResponse response,
                               @NonNull RequestHandler handler) {
        RequestBody body = request.getBody();
        try {
            if (body != null) {
                String _body = body.string();  // 第一次读取, 不会 empty string
                Log.d(TAG, "Body: " + _body);
            }
        } catch (IOException e) {
            Log.e(TAG, "onIntercept: ", e);
        }
        return false;
    }
}

我之后的 controller 再 call body.string() 就会 null 了

@RestController
@RequestMapping(path = "/api")
public class RouterController {
    @PostMapping(path = "/execute")
    public StringBody showPage(HttpRequest request, @Nullable RequestBody body) throws IOException {
        String bodyContent = body.string();   // 永远都拿到 empty string
        Log.d(TAG, "showPage: body = " + bodyContent); // bodyContent 是 empty string
    }
}

我如果移除掉我的 LoggerInterceptor class 或者不在里头 call body.string(), 我的 RouterController 里头第一次 call 的 body.string() 就不会 empty string 了.

问：有没有别的办法可以在 LoggerInterceptor 和 我的 RouterController 里头都 call body.string()呢？

[yanzhenjie]

流只能被读取一次，确实有这个设计缺陷，目前我也没好办法，我再想下怎么解决~

[Heart-Beats]

流只能被读取一次，确实有这个设计缺陷，目前我也没好办法，我再想下怎么解决~

这个是不是可以模仿 OkHttp 里的设计：

OkHttp 里的 request 可以通过这个重新构建一个实例取得其中的 body

[Heart-Beats]

大佬，这个问题有考虑修复支持吗？目前在 HandlerInterceptor 中获取 body 进行处理的场景还是比较多见的，比如：日志打印、请求验签等。

我这边根据使用对这块相关流程进行 debug 发现，应用上层即使缓存了 fun onIntercept(request: HttpRequest, response: HttpResponse, handler: RequestHandler) 参数 HttpRequest 的 RequestBody，保证后续可以重复使用，还是会存在以下的报错：

跟踪相关源码找到处理逻辑：

可以知道 request 中的 body 流正常只要被拦截器给消费了，那么 handler.handle(request, response) 处理数据时，再获取相关数据肯定就失败了。在这其中我一开始尝试解决时，采用的是代理 HttpRequest，让其支持可复用获取 body，很可惜最终还是报一样的错误，写法如下：

	override fun onIntercept(request: HttpRequest, response: HttpResponse, handler: RequestHandler): Boolean {
		val repeatableHttpRequest = RepeatableHttpRequest(request)

		// 打印请求信息
 		logRequest(request)

		// 继续处理请求
		val result = handler.handle(request, response)

		// 打印响应信息
		logResponse(response)

		return false
	}

我原以为 RepeatableHttpRequest 的实现存在问题，经过 debug 发现根源在：

原因也显而易见，因为在 DispatcherHandler 中，拦截器处理之后才调用 request.setAttribute(HttpContext.HTTP_MESSAGE_CONVERTER, mConverter);，这其实也暴露了一个设计问题， RequestHandler 的 handle() 方法应不应该向用户暴露，至少目前我看下来即使拦截器中拦截处理调用 RequestHandler 的 handle() 方法，保持对 handler 的处理与 DispatcherHandler 中一致实现还是很难。

在我后面转变思路后认为应该对 body() 流进行处理，发现该思路会更正确一下，我跟踪 request 的 body 获取，发现这块如果能解决应该问题会更简单一些，我跟踪当时对应的 request 为 StandardRequest， 找到对应的方法：

[Heart-Beats]

核心点其实在于：mEntity.getContent()，只要保证其能复用，就可以实现流的的多次读取，但是我这边目前无法直接查看 HttpEntity 的源码，但是通过之前找的方案，目前思路有以下两个：

1. 获取 mEntity.getContent() 的数据后，缓存起来，支持后续多次使用，就像 RepeatableRequestBody 的实现一样：

2. 代理 mEntity.getContent() 对应的输入流，让其支持标记：
   InputStream 有一个 markSupported() 方法，配套 reset() 一起使用，BufferedInputStream 与 ByteArrayInputStream 均实现了相关方法

但是这两点从上层修改均比较麻烦，希望大佬看看是否可以优化支持一下

[Heart-Beats]

已经修改完成，可以参考这个提交：13626a7b91bf0d3c063688c48267e45b470101ad。

如若不自己克隆修改，也可直接使用：

def andserverVersion = '2.1.12'
implementation("io.github.heart-beats.andserver:api:$andserverVersion")
kapt("io.github.heart-beats.andserver:processor:$andserverVersion")