Is it possible to disable all the cache features from AFNetworking?
I am building my own custom cache system and don't want this to take up disk space too.
Thanks, Ashley
Is it possible to disable all the cache features from AFNetworking?
I am building my own custom cache system and don't want this to take up disk space too.
Thanks, Ashley
This may depend on your server implementation, but adding
Cache-Control:no-store
header to your outgoing request should result in a response that contains the same header, thus commandingNSURLCache
to not cache the response to disk.IMHO this is a better approach than disabling disk-caching completely, especially if you're writing SDK code that will be used by other applications which may want to utilize
NSURLCache
.I've found on iOS 6 that requests are sometimes cached, even if the request has
NSURLRequestReloadIgnoringCacheData
. Adding a cache response block that returnsnil
prevents the request from being cached.Unfortunately non of these methods worked for me. The only way I've managed to get the cache disabled is this way:
Here's the original answer
Initially I found Jason Moore's answer to work, however recently I have noticed my app is still caching requests. I am not using the latest AFNetworking, so I do not know if caching has been addressed in more recent builds.
Apple's URLCache Project has this to say:
And then does this to disable the cache.
This will disable all caching for your whole app, which may not be ideal in some situations, but as
NSURLRequest
is not honouring the requested cache policy, it is the only option left that I can see.Cacheing is handled application-wide by
NSURLCache
. If you don't set a shared cache, requests are not cached. Even with a sharedNSURLCache
, the default implementation on iOS does not support disk cacheing anyway.That said, unless you have a very particular reason to write your own cacheing system, I would strongly recommend against it.
NSURLCache
is good enough for 99.9% of applications: it handles cache directives from incoming responses and uses them appropriately with new requests, and does so automatically in a way that is unlikely to be a performance bottleneck in your application. As someone who has wasted untold hours making one myself (and later throwing it away since it was completely unnecessary), I'd say that there are much better places to focus your development attention.