OkHttp 响应缓存返回垃圾文本

Posted 2023-03-22

【中文标题】OkHttp 响应缓存返回垃圾文本

【英文标题】：OkHttpResponseCache returning garbaged text

【发布时间】：2013-12-03 12:36:07

【问题描述】：

有没有人在经过身份验证的 HTTPS 连接上成功使用 OkHttpResponseCache？我正面临这种奇怪的行为，第二次从缓存中提供内容时它返回垃圾而不是正确的内容。

我作为示例使用的服务受 HTTP 基本身份验证保护并通过 HTTPS 访问。我添加了 must-revalidate 响应标头以允许缓存存储响应。它使用 ETags 作为缓存验证机制。

它非常适合第一个缓存响应：

1 - 我第一次进行服务调用时，服务器返回 200 OK。调试响应缓存源代码如果传递给 put() 方法（将其存储在文件存储中），我可以看到响应。

2 - 发出第二个请求。服务器被命中并返回 304 响应。检查缓存标头和单步调试确认服务器确实返回了 304。一个奇怪的行为很棘手：在第二个响应（现在由缓存提供服务）上，ETag 标头现在包含重复的值（而不是具有单个值，它该值在列表中有两次）。

3 - 我提出第三个请求。与上面相同的行为，ETag 值的相同“重复”，但是当我得到输入流时，而不是正确的 json 文本，我得到了垃圾（就像一堆黑色菱形里面有一个询问）。

我不知道我是否做错了什么（配置缓存时）。我不知道这是否是编码问题，或者缓存是否尝试更新文件存储并弄乱了输入。我怀疑在第一次缓存响应之后（在第二次尝试中），第二个 ETag 值的存在会使标头无效，并且缓存尝试再次存储响应并最终将其弄乱。我还不能通过它进行单步调试来确认。

我尝试用 UTF-8、16、ASCII、ISO “翻译”垃圾文本，但无济于事。我尝试使用 HTTP 而不是 HTTPS 并得到了相同的行为。

是否有人遇到过类似的事情并能够解决？是缓存中的错误还是我做错了什么？

【参考方案1】：

在执行条件 GET 时，OkHttp 更新 Content-Encoding: gzip 标头的方式存在错误。它已在 OkHttp 1.3 中修复。

【讨论】：

谢谢。有时间我会再试一次。