【发布时间】:2015-05-20 16:40:55
【问题描述】:
我今天在检查 Charles Proxy 中的请求和响应标头时发现(可能)NSURLCache 存在问题。这个问题有点令人困惑,但我能够始终如一地重现它:
简而言之,这个问题与使用 iOS 的原生 NSURLCache 和默认策略缓存 NSURLRequests 有关。事实证明,只要响应具有标头transfer-encoding: chunked,请求就不会被缓存。但是,如果响应头是content-length: xxx,则缓存工作正常。具体来说,似乎当响应被分块时, NSURLCache 不会保存 eTag 并且也忽略将 if-none-match 标头附加到相同 url 的后续请求,因此缓存失败(应该如此),即 200 是返回而不是 304。
我正在 iOS8.2 模拟器上进行测试。即使您没有解决方案,我也很想知道您是否遇到过同样的问题。我至少找到了one similar report),这是related thread posted by my back-end engineer。
【问题讨论】:
-
嗨,这有什么更新吗?
-
无,除非我们能够高度确定地重现此错误。目前,我们正在研究始终将带有 content-length 标头的 JSON 发送回。您的问题的性质是什么?
-
您好,我们的后端系统无法返回内容长度,因为响应很大,必须以块的形式返回。所以我们需要找到缓存分块响应的方法或官方文档说这是不可能的。感谢任何建议。
-
嗨,在这里查看我的答案:stackoverflow.com/questions/20248707/…
标签: ios swift caching ios8 nsurlcache