apache / apache/servicecomb-java-chassis
通过REST接口下载的二进制文件与原始文件不一致
- 主要言語
- Java
- スター
- 1.9k
- フォーク
- 814
- 平均マージ
- 8日 23時間
- マージ済み PR(30日)
- 1
説明
java-chassis-dependencies版本:2.6.0
文件下载流程:浏览器---》服务A接口---》服务B接口
接口响应信息:
服务B接口返回类型:FilePart
服务A接口返回类型:ReadStreamPart
**问题现象:
直接使用Postman调用服务B接口下载文件与原始文件二进制一致
使用Postman调用服务A接口下载文件与原始文件不一致
通过浏览器下载文件与原始文件不一致**
参考文件下载开发指导:https://huaweicse.github.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/general-development/file-download.html
1. 服务提供者是可以直接返回Part类型(FilePart、ReadStreamPart都是Part实现)
`如果需要根据请求参数动态创建临时文件,下载完成后,将临时文件删除,可以采用 Part 类型的参数。
@GetMapping(path = "/file")
public Part file(String content) throws IOException {
File file = createTempFile(content);
return new FilePart(null, file)
.setDeleteAfterFinished(true)
.setSubmittedFileName("test.txt");
}`
2. 服务消费者统一使用 org.apache.servicecomb.foundation.vertx.http.ReadStreamPart 处理文件下载。
服务A也是使用ReadStreamPart接收的服务B的响应,由于目的是把文件返回给用户,所以直接将ReadStreamPart透传给web端
在文档中看到关于ReadStreamPart的如下描述,感到很疑惑:
**在得到ReadStreamPart实例时,并没有完成文件内容的下载,调用save系列方法才开始真正从网络上读取文件数据。**
**请问,ReadStreamPart不能在接口间透传吗?为什么文本文件不会出错,对于部分二进制文件会出现下载后不一致的情况?**
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
調査の方向性
参照されているファイルダウンロードガイドを読み、Service B FilePart から Service A ReadStreamPart、さらにブラウザーに至るパスを追跡してください。Postman とブラウザーでバイナリの不一致を再現し、その後 ReadStreamPart の保存動作と Part の実装を調査してください。passthrough がサポートされているかを説明し、検証済みの修正またはドキュメントの変更を特定できれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- api, backend
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100