EOFException: null при применении gzip к dropwizard вместе с фильтром

Мы сталкиваемся с исключением при использовании dropwizard-core:1.1.2 при попытке добавить кодировку содержимого gzip в заголовки ответов службы. Подробности следующие:

GzipFilter.class

public class GzipFilter implements Filter {

    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)
            throws IOException, ServletException {
        HttpServletResponse response = (HttpServletResponse) res;
        response.setHeader("Content-Encoding", "gzip");
        chain.doFilter(req, res);
    }

    public void init(FilterConfig filterConfig) {
    }

    public void destroy() {
    }
}

Service.class

@Override
public void run(DocumentServiceConfig config, Environment environment) throws Exception {
    Injector injector = createInjector(config, environment);



environment.jersey().register(injector.getInstance(SomeResource.class));
     environment.servlets().addFilter("Gzip-Filter", GzipFilter.class).addMappingForUrlPatterns(EnumSet.allOf(DispatcherType.class), true, "/*");

config.yml

gzip:
  enabled: true
  minimumEntitySize: 256B
    bufferSize: 32KB

Трассировка стека исключений для ответа 500 API –

WARN  [2017-08-04 00:48:20,713] org.eclipse.jetty.server.HttpChannel: /clients/v2
! java.io.EOFException: null
! at java.util.zip.GZIPInputStream.readUByte(GZIPInputStream.java:268)
! at java.util.zip.GZIPInputStream.readUShort(GZIPInputStream.java:258)
! at java.util.zip.GZIPInputStream.readHeader(GZIPInputStream.java:164)
! at java.util.zip.GZIPInputStream.<init>(GZIPInputStream.java:79)
! at io.dropwizard.jetty.BiDiGzipHandler.wrapGzippedRequest(BiDiGzipHandler.java:100)
! at io.dropwizard.jetty.BiDiGzipHandler.handle(BiDiGzipHandler.java:64)
! at org.eclipse.jetty.server.handler.RequestLogHandler.handle(RequestLogHandler.java:56)
! at org.eclipse.jetty.server.handler.StatisticsHandler.handle(StatisticsHandler.java:169)
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
! at org.eclipse.jetty.server.Server.handle(Server.java:564)
! at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
! at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
! at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
! at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
! at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
! at org.eclipse.jetty.util.thread.Invocable.invokePreferred(Invocable.java:122)
! at org.eclipse.jetty.util.thread.strategy.ExecutingExecutionStrategy.invoke(ExecutingExecutionStrategy.java:58)
! at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:201)
! at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:133)
! at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
! at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
! at java.lang.Thread.run(Thread.java:745)

gzip dropwizard gzipinputstream
person Naman    schedule 03.08.2017    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Смущен, хотя должен ли я ответить на это сам. Тем не менее, поскольку детали обновления частично решают проблему, поэтому я отвечаю на это сам.

Далее описал то же самое в Dropwizard#Issues#2126

Цитирование @arteam здесь, чтобы предоставить решение для текущей реализации.

Я считаю, что Dropwizard автоматически сжимает gzip. Поддержка gzip включена по умолчанию (см. http://www.dropwizard.io/1.1.2/docs/manual/configuration.html#gzip). Таким образом, если клиент поддерживает распаковку, отправив запрос с заголовком Accept-Encoding:gzip, org.eclipse.jetty.server.handler.gzip.GzipHandler сожмет ответ и добавит заголовок Content-Encoding: gzip.

Ну, вопрос все еще остается, хотя я до сих пор не отмечаю это как ответ на этот вопрос:

Почему ваш пользовательский фильтр не работает, неясно, возможно, ваш фильтр выполняется до сервлета из Джерси и перезаписывает заголовок.

Итак, все, что нужно было сделать, это реализовать изменения service.yml следующим образом:

gzip:
  enabled: true
  minimumEntitySize: 256B
    bufferSize: 32KB

и не реализовывать какой-либо CustomFilter, который в конечном итоге переопределяет текущую реализацию, а не просто переопределяет, но приводит к названному исключению.

Еще один момент, который следует отметить, заключается в том, что это должно быть проверено на размер ответа как больше, так и меньше, чем minimumEntitySize, как указано в конфигурации.

person Naman    schedule 28.08.2017