NSURLCache cachedResponseForRequest не извлекает кэшированные данные

Я пытаюсь получить ранее кэшированную информацию из NSURLCache. С этим кодом:

NSString *theCompleteURL = @"http://192.168.1.2:8080/api/endpoint.json";
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:theCompleteURL]];

NSCachedURLResponse *response = [[NSURLCache sharedURLCache] cachedResponseForRequest:request];
if (response) {
    NSLog(@"Cached data found");
}
else {
    NSLog(@"Cached data not found");
}

Но я всегда получаю nil в качестве ответа на переменную «ответ» из метода cachedResponseForRequest.

Я уверен, что данные находятся внутри кеша, потому что я проверил их в файле Cache.db моего приложения, получив этот результат из таблицы cfurl_cache_response:

sqlite> select * from cfurl_cache_response;
1|0|1875686237|0|http://192.168.1.2:8080/api/endpoint.json|2014-01-09 11:55:17|
sqlite>

В ApplicationDelegate NSURLCache настроен как:

NSURLCache *cache = [[NSURLCache alloc] initWithMemoryCapacity:5 * 1024 * 1024
                                                  diskCapacity:40 * 1024 * 1024
                                                      diskPath:nil];

[NSURLCache setSharedURLCache:cache];

Любая идея о том, что может происходить с кешем?

Заголовки моих конечных точек выглядят так:

$ curl -I http://192.168.1.2:8080/api/endpoint.json
HTTP/1.1 200 OK
Content-Length: 1385
Expires:  Thu, 01 Dec 2020 16
00: 00 GMT
Content-Type: application/json;charset=utf-8
ETag:  "3e86-410-3596fbbc"
Cache-Control:  max-age=3600
Connection: keep-alive
Server: thin 1.5.1 codename Straight Razor
$

ios networking caching nsurlcache
person David Cordero    schedule 09.01.2014    source источник
comment
Пожалуйста, опубликуйте заголовки ответов. Пожалуйста, напишите код, где данные должны быть помещены в кеш   -  person danh    schedule 09.01.2014
comment
Отредактировано, чтобы добавить заголовки   -  person David Cordero    schedule 09.01.2014
comment
где вы можете решить это?   -  person estemendoza    schedule 17.03.2014
comment
Сброс содержимого и настроек в симуляторе iOS исправил это для меня.   -  person guoc    schedule 14.03.2017

Ответы (1)


arrow_upward
1
arrow_downward

Это можно объяснить заголовками, связанными с ответом, в частности, полями Cache-control и Etag. См. также здесь:

13.1.3 Механизмы управления кэшем

Базовые механизмы кэширования в HTTP/1.1 (указываемые сервером сроки действия и валидаторы) являются неявными директивами для кэшей. В некоторых случаях серверу или клиенту может потребоваться предоставить явные директивы кэшам HTTP. Для этой цели мы используем заголовок Cache-Control.

Заголовок Cache-Control позволяет клиенту или серверу передавать различные директивы в запросах или ответах. Эти директивы обычно переопределяют алгоритмы кэширования по умолчанию. Как правило, при наличии очевидного конфликта между значениями заголовков применяется наиболее ограничительная интерпретация (то есть та, которая с наибольшей вероятностью сохранит семантическую прозрачность).

13.3.2 Валидаторы кэша тегов сущностей

Значение поля заголовка ответа ETag, тэг сущности, обеспечивает «непрозрачный» валидатор кэша. Это может обеспечить более надежную проверку в ситуациях, когда неудобно хранить даты модификации, когда односекундного разрешения значений даты HTTP недостаточно или когда исходный сервер хочет избежать определенных парадоксов, которые могут возникнуть при использовании дат модификации. .

Вы можете найти здесь допустимые значения для Cache-control и здесь для Etag.

person sergio    schedule 09.01.2014
comment
Я добавил свои заголовки к исходному вопросу. Прочитав эти ссылки, они, видимо, правы. Я использую Etag и max-age=3600, также пробовал с Cache-control равным max-age=3600, public с точно таким же результатом. - person David Cordero; 09.01.2014