Отправка файла .gz через CURL в RESTful, создавая ZipException в GZIPInputStream - PullRequest
Новая
       17

Отправка файла .gz через CURL в RESTful, создавая ZipException в GZIPInputStream

0 голосов
/ 01 июня 2018

Приложение, которое я создаю, принимает сжатый файл, отправленный в RESTful PUT, разархивирует файл и затем выполняет дальнейшую обработку следующим образом: 

public class Service {

  @PUT
  @Path("/{filename}")
  Response doPut(@Context HttpServletRequest request,
      @PathParam("filename") String filename,
      InputStream inputStream) {

      try {
        GZIPInputStream gzipInputStream = new GZIPInputStream(inputStream);

        // Do Stuff with GZIPInputStream
      } catch (IOException e) {
        e.printStackTrace();
      }
      return null;
  }
}

Я могу успешно отправить сжатый файл в блокепроверить так: 

InputStream inputStream = new FileInputStream("src/main/resources/testFile.gz);
Service service = new Service();
service.doPut(mockHttpServletRequest, "testFile.gz", inputStream);
// Verify processing stuff happens

Но когда я собираю приложение и пытаюсь CURL того же файла из каталога src / main / resources со следующим, я получаю исключение ZipException: 

curl -v -k -X PUT --user USER:Password -H "Content-Type: application/gzip" --data-binary @testFile.gz https://myapp.dev.com/testFile.gz

Исключение составляет: 

java.util.zip.ZipException: Not in GZIP format
    at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:165)
    at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)
    at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:91)
    at Service.doPut(Service.java:23)
    // etc.

Так есть ли у кого-нибудь идеи, почему отправка файла через CURL приводит к возникновению исключения ZipException?

Обновление: в итоге я посмотрел фактические отправляемые байтычерез InputStream и выяснил, откуда возникла ошибка ZipException: Not in GZIP.Первые два байта файла GZIP должны быть 1F и 8B соответственно, чтобы GZIPInputStream мог распознать данные в формате GZIP.Вместо этого 8-байтовый байт вместе с каждым другим байтом в паре, который не соответствует действительному символу UTF-8, был преобразован в байты EF, BF, BD, которые являются байтами замены неизвестного символа UTF-8.Таким образом, сервер читает данные GZIP в виде символов UTF-8, а не в двоичном формате, и портит данные.

Проблема, с которой я столкнулся сейчас, заключается в том, что я не могу понять, где мне нужно изменить конфигурацию вчтобы сервер обрабатывал сжатые данные как двоичные по сравнению с UTF-8.Приложение использует Jax-rs на сервере Джерси с использованием Spring-Boot, который развертывается в модуле Kubernetes и запускается как служба, поэтому необходимо настроить что-то в настройке одной из этих технологий, чтобы предотвратить использование неправильного кодирования на сервере.data.

Я попытался добавить -H "Content-Encoding: gzip" к команде curl, зарегистрировать EncodingFilter.class и GZipEncoder.class в классе ResourceConfig jersey, добавив application / gzip в server.compression.mime-types в application.propertes, добавление аннотации @Consumes ("application / gzip") к методу doPut, описанному выше, и некоторые другие вещи, которые я не могу вспомнить, но ничто не оказывает никакого влияния.

В подробных журналах CURL я вижу следующее: 

> PUT /src/main/resources/testFile.gz
> HOST: my.host.com
> Authorization: Basic <authorization stuff>
> User-Agent: curl/7.54.1
> Accept: */*
> Content-Encoding: gzip
> Content-Type: application/gzip
> Content-Length: 31
>
} [31 bytes data]
* upload completely sent off: 31 out of 31 bytes
< HTTP/1.1 500
< X-Application-Context: application
< Content-Type: application/json;charset=UTF-8
< Transfer-Encoding: chunked
< Date: <date stuff>
...etc

Ничто из того, что я сделал, не повлияло на принимающую сторону 

Content-Type: application/json;charset=UTF-8

, которая, как я подозреваю, является частьювопрос.

...