破損したZIPファイルには、私のようなものを持っているRESTサービスからzipファイルをダウンロードした後、

Question

問題があるダウンロード：

HTTP/1.1 200 OK 
Server: Apache-Coyote/1.1 
Content-Disposition: attachment; filename=Report_request_2681.zip 
Content-Type: application/octet-stream 
Content-Length: 1843 
Date: Tue, 24 May 2016 15:24:39 GMT 

PK etc etc... my real zip file bytes 

生成されたzipファイルが正しいか（直接からそれをコピーしてみましたサーバー、サイズは1843バイトです）、エラーはダウンロード方法にあります（HTTPヘッダーをファイルに追加するので、最終サイズは1843バイト+ヘッダー部分です）。私はresteasy 2.1.0 GAを使用してい

@Produces(MediaType.APPLICATION_OCTET_STREAM) 
@Path("/download/{fileName}") 
Response getRequestedFile(
     @Context HttpServletRequest httpRequest, 
     @PathParam("fileName") String fileName 
); 

    //... bla bla bla method and authentication stuff 

    //Prepare a file object with file to return 
    File file = new File(myPath); 
    if (!file.exists()) { 
     return Response.status(Response.Status.NOT_FOUND).build(); 
    } 

    try { 
     return Response.ok(FileUtils.readFileToByteArray(file), MediaType.APPLICATION_OCTET_STREAM_TYPE).header("Content-Disposition", "attachment; filename=\"" + cleanFileName + "\"").build(); 
    } catch (IOException ex) { 
     return Response.status(Response.Status.INTERNAL_SERVER_ERROR).build(); 
    } 

（と私はそれをアップグレードすることはできません）：ここでは私のresteasy実装です（私は非影響力のある部分を削除しました）。方法readFileToByteArrayはorg.apache.commons.io.FileUtilsから取られます。私はコンテンツをtext/plainまたはapplication/zipに設定し、FileInputStreamをResponseに渡そうとしましたが、問題は解決しません。任意のヒント？

HTTP/1.1 200 OK 
Server: Apache-Coyote/1.1 
Content-Disposition: attachment; filename="Report_request_2681" 
Content-Type: application/octet-stream 
Content-Length: 16550 
Date: Wed, 25 May 2016 07:03:20 GMT 

...rest of my txt file 

編集：

ああ、私はまた、私はHTTPレスポンスヘッダを持ってダウンロードしたファイルの開始時に、単純なテキストファイル...同じ問題をREST方式を経由してダウンロードを試してみました：質問の統合コメント情報。

Answer 1

回避策として、私はこの問題を解決できませんでした。新しいURLからファイルをダウンロードするサーブレットを作成しました。そのため、resteasyの実装を次のように変更しました。

.... 
String redirectPath = StringUtils.substringBefore(httpRequest.getRequestURL().toString(), "restws") + "download?fileName=" + fileName + "&actionId=" + actionRequestId + "&check=" + encodedString; 
return Response.seeOther(URI.create(redirectPath)).build(); 

checkパラメータはsimmetricセキュリティのために使用されるタイムスタンプを含む、簡単なエンコードされたトークンです：リダイレクトを実行します。サーブレット内の認証/役割ロジックの完全なポートを回避しました（サーブレットURLがRESTメソッドから3秒以内に呼び出されない場合、リクエストは400を返します）。 優雅な解決策ではありませんが、少なくとも今ではファイルは破損していません。

P.S.ちなみに、ちょうどメモとして：WinRARは壊れたファイルを処理します（7zipバージョン9.2）、Windows Explorerと7zipの最後のバージョンはそれを開くことができません。