OkHttpResponseCache, возвращающий мусорный текст

Question

Кто-нибудь использовал OkHttpResponseCache для аутентифицированного HTTPS-соединения успешно? Я столкнулся с этим странным поведением, когда второй контент доставляется из кеша, он возвращает мусор вместо правильного контента.

Служба, которую я использую в качестве примера, защищена базовым протоколом HTTP и доступна через HTTPS. Я добавил заголовок ответа с обязательным повторением, чтобы кеш мог сохранить ответ. Он использует ETags в качестве механизма проверки кеша.

Он отлично работает в первый кэшированных ответ:

1 - Первый раз, когда я сделать вызов службы, возврат 200 сервера OK. Отлаживая исходный код кэша ответа, я мог видеть ответ, если он передан методу put() (который хранит его в хранилище файлов).

2 - Второй запрос выполнен. Сервер удаляется и возвращает ответ 304. Проверка заголовков кеша и отладка шага подтвердили, что сервер действительно вернулся 304. Одно странное поведение жесткое: во втором ответе (теперь обслуживаемом кешем) заголовок ETag теперь содержит дублируемое значение (вместо того, чтобы иметь одно значение, оно имеет это значение в списке дважды).

3 - Я делаю третий запрос. Такое же поведение, как и выше, такое же «дублирование» значения ETag, но когда я получаю входной поток, вместо правильного текста json, я получаю мусор (как в кучке черных алмазов с допросом внутри).

Я не знаю, что я делаю что-то неправильно (при настройке кеша). Я не знаю, является ли это проблемой кодирования, или если кэш попытался обновить хранилище файлов и испортил ввод. Я подозреваю, что после первого ответа на кеш (во второй попытке) наличие второго значения ETag делает недействительными заголовки, а кеш пытается сохранить ответ еще раз и заканчивает его испортить. Мне еще не удалось отладить его, чтобы подтвердить это.

Я попытался «перевести» мусорный текст с UTF-8, 16, ASCII, ISO безрезультатно. Я попытался использовать HTTP вместо HTTPS и получил то же поведение.

Кто-нибудь сталкивался с чем-то похожим и смог его решить? Это ошибка в кеше или я могу делать что-то неправильно?

Answer 1

Была ошибка в том, что OkHttp обновляет заголовок Content-Encoding: gzip при выполнении условных GET. Это исправлено в OkHttp 1.3.