Библиотека WS и заголовки Content-Encoding/Accept-Encoding

Я не уверен, что здесь проблема со спреем или с Play Framework.

У меня есть сервер API, работающий на Spray, к которому я отправляю запросы из приложения Play, используя библиотеку WS. На моем маршруте Spray я использую директиву compressResponseIfRequested. Когда я делаю запросы с помощью curl, я вижу, что длина содержимого короче, чем без сжатия, и что заголовок кодирования содержимого возвращается как «gzip».

Однако, когда я делаю запрос, используя WS lib из Play, длина содержимого — это длина несжатого ответа, и, действительно, заголовок кодирования содержимого отсутствует. Это так, хотя я включаю в запрос заголовок Accept-Encoding: gzip. Я даже вижу, когда я регистрирую заголовки ответов внутри своего приложения Spray, когда оно выполняет запрос, что заголовок Content-Encoding: gzip присутствует.

Что я здесь делаю неправильно? Будем очень признательны за любые предложения по дальнейшей отладке.


person LuxuryMode    schedule 23.01.2015    source источник


Ответы (1)


Это может показаться слегка безумным предложением, но рассмотрите возможность использования альтернативной клиентской библиотеки HTTP, в частности, я бы рекомендовал OkHttp .

OkHttp — отличная современная библиотека асинхронного HTTP на основе Java, которая поддерживает множество замечательных вещей, таких как SNI, дисковое кэширование ETag и т. д. Она была принята в качестве базовой клиентской библиотеки HTTP в последних версиях Android. Я использовал его несколько раз в качестве замены библиотеки Play-WS (которая называется Netty) для решения проблем. на основе, как Dispatch). OkHttp легко обернуть для использования Scala, посмотрите файлы, измененные в этом запросе на включение:

https://github.com/guardian/prout/pull/9/files#diff-1

Определенно стоит попробовать OkHttp!

person Roberto Tyley    schedule 23.01.2015