httpclient4 download file 下载文件 CRLF expected at end of chunk

文件 CRLF expected at end of chunk"/>

httpclient4 download file 下载文件 CRLF expected at end of chunk

原文发表于：.html

异常信息

前段时间，某业务场景需要调用第三方系统进行文件下载，结果发现文件下载的时候，CRLF expected at end of chunk。

org.apache.http.MalformedChunkCodingException: CRLF expected at end of chunkat org.apache.http.impl.io.ChunkedInputStream.getChunkSize(ChunkedInputStream.java:250) ~[httpcore-4.4.11.jar!/:4.4.11]at org.apache.http.impl.io.ChunkedInputStream.nextChunk(ChunkedInputStream.java:222) ~[httpcore-4.4.11.jar!/:4.4.11]at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:183) ~[httpcore-4.4.11.jar!/:4.4.11]at org.apache.http.impl.io.ChunkedInputStream.read(ChunkedInputStream.java:210) ~[httpcore-4.4.11.jar!/:4.4.11]at org.apache.http.impl.io.ChunkedInputStream.close(ChunkedInputStream.java:312) ~[httpcore-4.4.11.jar!/:4.4.11]at org.apache.http.impl.execchain.ResponseEntityProxy.streamClosed(ResponseEntityProxy.java:142) ~[httpclient-4.5.8.jar!/:4.5.8]at org.apache.http.conn.EofSensorInputStream.checkClose(EofSensorInputStream.java:228) ~[httpclient-4.5.8.jar!/:4.5.8]at org.apache.http.conn.EofSensorInputStream.close(EofSensorInputStream.java:172) ~[httpclient-4.5.8.jar!/:4.5.8]at java.util.zip.InflaterInputStream.close(InflaterInputStream.java:227) ~[na:1.8.0_322]at java.util.zip.GZIPInputStream.close(GZIPInputStream.java:136) ~[na:1.8.0_322]at org.apache.http.client.entity.LazyDecompressingInputStream.close(LazyDecompressingInputStream.java:94) ~[httpclient-4.5.8.jar!/:4.5.8]

全选代码

复制

下载代码

HttpEntity httpEntity = null;InputStream fileInputStream =null;ByteArrayOutputStream fileByteArrayOutputStream=null;try (CloseableHttpClient closeableHttpClient = httpClientBuilder.build();CloseableHttpResponse closeableHttpResponse = closeableHttpClient.execute(httpUriRequest)) {HttpClientFileDownloadResult download=new HttpClientFileDownloadResult();String contentType=null ;if(closeableHttpResponse.containsHeader("content-type")) {contentType=closeableHttpResponse.getHeaders("content-type")[0].getValue();}String result= null;String contentDisposition = null;if(closeableHttpResponse.containsHeader("content-disposition")) {contentDisposition = closeableHttpResponse.getHeaders("content-disposition")[0].getValue();LOGGER.info("content-type:{},contentDisposition:{}",contentType,contentDisposition);}if (ContentType.DEFAULT_BINARY.getMimeType().equals(contentType)) {String[] contentDispositionArray = contentDisposition != null ? contentDisposition.split(";"): new String[] {};for (String value : contentDispositionArray) {if (value.trim().startsWith("filename")) {String filename = value.substring(value.indexOf('=') + 1).trim().replace("\"", "");download.setFileName(new String(filename.getBytes(),"utf-8"));break;}}result=download.getFileName();httpEntity = closeableHttpResponse.getEntity();ByteArrayOutputStream bos=new ByteArrayOutputStream();fileInputStream = httpEntity.getContent();IOUtils.copy(fileInputStream, bos);download.setFileContent(bos.toByteArray());}else {httpEntity = closeableHttpResponse.getEntity();result=EntityUtils.toString(httpEntity, charset);download.setResponseBody(result);}download.setHeaderContentType(contentType);return download;} finally {//如果没有try {if(fileInputStream!=null) {fileInputStream.close();}} catch (Exception e) {//结果发现这个报错LOGGER.error("fileInputStream close error:"+e.getMessage());}//如果 没有fileInputStream.close();这个报错，finally try-catch只是把错误提前了，做了个代码兼容EntityUtils.consume(httpEntity);}//EntityUtils.consume(httpEntity); 这个报错，所有finally加上了这个fileInputStream.close();/*** Ensures that the entity content is fully consumed and the content stream, if exists,* is closed.** @param entity the entity to consume.* @throws IOException if an error occurs reading the input stream** @since 4.1*/public static void consume(final HttpEntity entity) throws IOException {if (entity == null) {return;}if (entity.isStreaming()) {final InputStream inStream = entity.getContent();if (inStream != null) {inStream.close();}}}

全选代码

复制

错误原因分析

抓取了response的headed信息

HTTP/1.1 200
Date:Wed, 27 Sep 2022 11:11:45 GMT
Content-Type:application/octet-stream
Transfer-Encoding:chunked
Connection:keep-alive
Vary:Accept-Encoding
Content-Disposition:attachment; filename="xxx.pdf";filename*=utf-8''xxx.pdf
Strict-Transport-Security:max-age=15724800; includeSubDomains
2022-09-17 11:11:45.890  util: content-type:Content-Type: application/octet-stream,contentDisposition:attachment; filename="xxx.pdf";filename*=utf-8''xxx.pdf

全选代码

复制

在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。

此应用场景外部文件系统是怕文件太大，进行了分块传输

HTTP 1.1时，Response要嘛通过Content-Length来指定要传输的内容大小，要嘛通过Transfer-Encoding: chunked来传输动态大小的内容，此时要求Response传输的内容要符合chunk encoding的规定。

从抓包的角度来说，两个请求如果HTTP 参数（Head和Body）都相同的话，是等价的，不管请求是从浏览器还是Java代码发出来的。
CRLF — Carriage-Return Line-Feed回车换行 回车(CR, ASCII 13, \r) 换行(LF, ASCII 10, \n)。
【carriage [‘kæridʒ] n. 运输；运费；四轮马车；举止；客车厢】

HTTP1.1默认 支持长连接（持久连接），长连接避免为每个请求都创建各自的连接，而是多个请求使用一个已经建立好的连接。如果每个HTTP请求都进行set up和tear down，这对于性能损失是非常严重的。

在长连接中，每次传输的长度必须都被计算的非常精确。如果在http头中以Content-Length来标记请求request或者响应response的大小，客户端或者服务器就只会从流中读取 Content-Length指定大小的字节，然后表明本次传输结束。使得下一次客户端请求以及服务器端响应 继续使用这个相同的socket连接成为可能。
在交互式应用程序中有1个问题，就是它并不知道将要传输的数据有多大。
在HTTP1.0中，服务器就会省略response头中的Content-Length而持续写数据出去，当服务器挂了的话，它简单地断开连接。而经典的HTTP客户端会一直读数据直到碰到-1（传输结束的标识符）。
为了处理这个问题，HTTP1.1中增加了一个特殊的header： Transfer-Encoding：chunked，允许响应response被分块chunked。每次向连接写数据的时候会先计算大小，最后在response的尾部以一个0长度的chunk块标志着此次传输的结束。即HTTP1.1支持chunked编码，它允许HTTP消息被分成多块后再进行传输。 Chunking一般用在服务器响应response的时候，但是客户端也可以chunk大的请求request。 即Chunk编码允许服务器在发送完Header后，发送更多的Body内容。
Chunked编码使用若干个Chunk块串连而成， 每个Chunk块都以一个表明chunk快大小的16进制数字和一个额外的CRLF（回车换行）开始，后面跟着指定大小的内容。即每个Chunk块分为头部和正文两部分，头部内容指定下一段正文的字符总数（十六进制的数字）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF)隔开。 最后以一个长度为0的Chunk表明本次传输结束 。

1个典型的Chunk传输例子：

C\r\n   
Some data...   
11\r\n   
Some more data...   
0\r\n  
上述消息内容包含2个chunk块，第一个块是12字节长度（hex C），第二个块是17字节长度（hex 11）。 

全选代码

复制

Java中减少Chunk数量的一种方法是不要适应flush（），只使用1个write（）方法来输出所有内容。如果被输出的内容大小大于output的buffer大小，那么输出还是会被chunk，但是不使用flush（）方法还是可以有效地减少不必要的chunking。
在有些情况下，有些客户端或者服务器只能处理老的HTTP1.0的行为。此时，应该使用 Connection: close的header来通知接收部分不要使用长连接。

Connection: keep-alive表明可以使用长连接。

解决办法方案

把CloseableHttpResponse closeableHttpResponse 抽取到外面，在finally 进行关闭CloseableHttpResponse ；

if(isOctetStream) {try {if(closeableHttpResponse!=null) {closeableHttpResponse.close();}} catch (Exception e) {LOGGER.error("response close error:",e);}}else {EntityUtils.consume(httpEntity);}

全选代码

复制

感谢参考文章：

原文发表于：.html

遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。：JAVA技术专家栈 » httpclient4 download file 下载文件 CRLF expected at end of chunk