@POST создает правильный архив .zip из октет-потока через Postman, но неверный через WebApp. - PullRequest
0 голосов
/ 15 марта 2019

У меня есть метод в JAVA, который производит .zip:

@POST
@Path("download")
@Produces(MediaType.APPLICATION_OCTET_STREAM)
@Consumes(MediaType.APPLICATION_JSON)
@RequesterAccess(privileges = XXX})
public void downloadFiles(@Context HttpServletResponse resp, Request 
req) {
    resp.setContentType("application/octet-stream");
    resp.setHeader(CONTENT_DISPOSITION_HEADER, 
"attachment;filename="xxx.zip");
    try {
        service.downloadFiles(resp.getOutputStream(), req);
(...)

Пока я выполняю POST через Postman и нажимаю кнопку «Сохранить и скачать», я получаю действительный архив .zip. Когда я пытаюсь загрузить его, используя WebBrowser и пользовательский интерфейс, написанный на JavaScript - я получаю поврежденный архив.

Запросы и ответы вместе с заголовками идентичны.

Вот код, ответственный за сохранение файла в JS:

saveFile(apiFunction: Observable<any>) {

apiFunction.subscribe(
  data => {
    let contentDisposition = data.headers.get('content-disposition') || '';
    let matches = /filename=([^;]+)/ig.exec(contentDisposition);
    let fileName = (...)
    var blob = new Blob([data._body], {
      type: 'application/octet-stream'
    });
    FileSaver.saveAs(blob, fileName);
  }, error => {
(...)

В обоих сценариях POST возвращает код состояния: 204. В чем может быть причина испорченного архива?

Edit: Я не очень разбираюсь в JS, но единственное различие, которое я заметил между двумя POST, состоит в том, что перед запросом POST от JS существует некоторый запрос OPTIONS, выполненный для той же конечной точки.

1 Ответ

0 голосов
/ 20 марта 2019

Проблема решена. Оказалось, что в этом архиве есть пути к записям, начинающиеся с "/", что прекрасно работает в Linux через Postman, но для Windows ZIP требуются относительные пути, поэтому в Windows и в браузерах архивы создавались / читались не правильно.

...