Block set by setDataTaskWillCacheResponseBlock on AFHTTPSessionManager is never called - objective-c

Question

I develop an application that relies heavily on AFNetworking to load data from a private API into Mantle models. My API client is a singleton subclass of AFHTTPSessionManager.
I'm trying to implement a basic offline mode by leveraging NSURLCache. The approach is to modify the request's cache policy on dataTaskWithRequest:request:completionHandler to NSURLRequestReturnCacheDataDontLoad if the AFNetworkReachabilityManager says the network is not reachable.
While I can verify that this actually works by using breakpoints during tests, the requests themselves are not being cached. I verified this by downloading the application container from Xcode, and checking the Cache.db sqlite file, which was empty. I also verified that I was looking at the correct cache by manually creating a dummy NSCachedURLResponse and forcefully storing it in the cache using storeCachedResponse:forRequest. Then the dummy response did show up in the Cache.db sqlite file.
So, I think I narrowed down the problem to my "usual" responses not being cached. I can also modify the headers sent by the server API. What I intend to do here is set a header Cache-Control: private on the API responses (so as not to make the other clients that use this API cache responses they shouldn't), and modify this cache header in the block of setDataTaskWillCacheResponseBlock, but this block never fires.
I understand that the URL system may decide when to call URLSession:dataTask:willCacheResponse:completionHandler, which calls the block, based on some undocumented rules, mainly the presence of a Cache-Control header, and the response size/cache size ratio. But my response is a 145-byte JSON, and the Cache-Control header is set (I verified both via curl -v and inspecting the task parameter of the success block of my request.
I also tried a more aggressive cache header, Cache-Control: public, max-age=2592000, to see if this caches the response or at least calls the block, but the behaviour was exactly the same. I also checked the myAFHTTPSessionManagerSubclass.session.delegate property, which was indeed pointing to myAFHTTPSessionManagerSubclass, as expected.
I also tried overriding URLSession:dataTask:willCacheResponse:completionHandler directly in my subclass, but it still was not called. Setting a breakpoint on this same delegate method on AFURLSessionManager.m in the Pods directory also does not work, the execution never stops on the breakpoint.
I'm using version 2.5.4 of AFNetworking, according to my Podfile.lock file.
So, how to make my responses cache (preferably without setting agressive caching policies on the response), so I can implement a quick offline mode in my app?
EDIT: I also tried to create a NSURLSession to see if this would work. So, I created a simple Node.js server that just answers something simple and sets a cache header:
$ curl -v http://192.168.1.107:1337/
* Hostname was NOT found in DNS cache
* Trying 192.168.1.107...
* Connected to 192.168.1.107 (192.168.1.107) port 1337 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.37.1
> Host: 192.168.1.107:1337
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain
< Cache-Control: public
< Date: Thu, 11 Jun 2015 14:38:14 GMT
< Connection: keep-alive
< Transfer-Encoding: chunked
<
Hello World
And then created a simple view controller to test:
- (void)viewDidLoad {
[super viewDidLoad];
// Prime the cache
[NSURLCache setSharedURLCache:[[NSURLCache alloc] initWithMemoryCapacity:2*1024 diskCapacity:10*1024*1024 diskPath:#"mytestcache"]];
// The sleep is to be absolutely sure the cache did initialise
sleep(2);
NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:nil];
[[session dataTaskWithURL:[NSURL URLWithString:#"http://192.168.1.107:1337"] completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
NSLog(#"Got response: %#", [[NSString alloc] initWithData:data encoding:NSASCIIStringEncoding]);
}] resume];
}
-(void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask willCacheResponse:(NSCachedURLResponse *)proposedResponse completionHandler:(void (^)(NSCachedURLResponse *))completionHandler {
completionHandler(proposedResponse);
}
The response is correctly printed, but willCacheResponse is never called (I set a breakpoint). I tried checking the container again, and the mytestcache directory was created, but it was empty. I also tried Cache-Control: max-age=86400, to the same result.
( cross-posted to AFNetworking issues at: https://github.com/AFNetworking/AFNetworking/issues/2780 )

Answer 1

Well, I will surprise you - the code you wrote above is working just fine, ...but it's incorrect for what you're trying to achieve ;)
Reason is simply - delegate methods are not being called when you create requests by method dataTaskWithRequest:completionHandler:. You need to use method dataTaskWithRequest: instead.
https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/URLLoadingSystem/Articles/UsingNSURLSession.html#//apple_ref/doc/uid/TP40013509-SW1 - read first Note
Second thing is that NSURLSession just really sux when we talk about caching. You may face several issues in iOS 7.x/8.x. I faced such nightmare when I was implementing custom cache in my app, which eventually has nothing in common with NSURLCache. Also I decided to create my kind of framework based on NSURLSession and AFNetworking.
One of the issues on iOS 7 is creating NSURLSession with defaultConfiguration, the NSURLCache object will be different than global one - quite unexpected behaviour.
One of the issues on iOS 8 is that the POST requests are also being cached, which may compromise security of your app. BTW https://www.google.pl/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=nsurlcache+ios+8+broken
Maybe it does not answer your questions, but you should be aware of that strange behaviours and differences between iOS versions.
Honestly I recommend you to use AFHTTPRequestOperationManager instead of AFHTTPSessionManager, because at least NSURLConnection works like a harm with NSURLCache :)