http响应头首部Content-Length - 程序员大本营

http响应头首部Content-Length

HTTP Content-Length深入实践-CSDN博客

用了这么久HTTP, 你是否了解Content-Length?-CSDN博客

 具体分析可看上面参考文章。

解决办法：可在请求头加上Content-Length，准确的长度，或者Transfer-Encoding：chunked

现象：一个简单的请求，正确返回了。

 @PostMapping("/getTokenTest")
    public String getTokenTest(@RequestBody User user) {
        return user.getUserName();
    }

日志却有java.io.EOFException: null

本人的情况是因为用的ApiPost发起的请求，Postman没有这种情况。因为postman默认给你加了Content-Length。

有这个错误信息的原因：

http1.1默认采用长连接Connection: keep-alive，但是你又没有告诉它报文结束的位置，所以就有异常信息EOFException打印出来了。

可以看下EOFException异常的解释:null表示在读取数据时，已经读到了文件或输入流的末尾，但是仍然尝试读取数据导致的异常。其中的null表示在读取时并没有读取到任何数据。在 Java 编程语言中，EOFException 是一个继承自 IOException 的异常类。通常情况下，当使用流读取数据时，如果已经到达了流的末尾，那么读取操作会返回 -1，表示已经没有更多的数据可以读取。但是如果继续进行读取操作，就会抛出 EOFException 异常

详细解释：

HTTP1.1采用了持久的连接，也就是一次TCP的连接不马上释放，允许许多的请求跟响应在一个TCP的连接上发送，所以客户机与服务器需要某种方式来标示一个报文在哪里结束和在下一个报文在哪里开始。简单的方法是使用呢content-length，但这只有当报文长度可以预先判断的时候才起作用，而对于动态的内容或者在发送数据前不能判定长度的情况下，可以使用分块的方法Transfer-Encoding：chunked来传送编码。

因为不知道正确的content-length长度，所以我们使用Transfer-Encoding：chunked分块，再次调用，发现日志不再打印EOFException异常。