iPhone SDK: Cache Policy & Cookie Handling in NSURLRequest

Ivan Moscoso, Tuesday, December 30, 2008 @ 11:21 am

I recently ran into an issue building an app which hit an existing (protected) website. Passing credentials along with each request, responses at first appeared to be cached, even after the user credentials changed from within the iPhone app. In sorting through this issue, it gave me a chance to get a bit more familiar with NSURLRequest, and NSURLRequestCachePolicy. As I later found, however, my problem turned out to be cookie-related..

Starting out, I assumed there to be a relationship between setting the cache policy on NSURLRequest and the behavior I would see when implementing connection:willCacheResponse: from within my delegate. When setting the cache policy to NSURLRequestReloadIgnoringLocalCacheData did not solve my problem, I implemented the latter delegate method in order to intercept any cached response.

I spent an hour or so of looking into this issue, with no success. Grabbing a late cup of coffee, I rolled back my changes and took a fresh look at things.

On the one hand, I was convinced by this point that the responses were not actually being cached. In fact, I felt had the feeling that the problem had nothing to do with cached responses at all. After double checking to make sure I was not holding on to the original credentials elsewhere in my code (stuffed inside an instance variable perhaps), it finally dawned on me that the problem might be related to the site I was connecting to, and its use of cookies to keep track of the user's identity after a successful login.

Fast forward ten minutes and one cup of coffee to the realization that this was indeed the case. Upon the first successful login, the site sets a cookie which NSURLRequest passes along on subsequent requests, even when the underlying credentials had changed! The fix here (in my adapter code) seemed pretty straightforward:

• When the user credentials change, ignore any cached responses
• When the user credentials change, invalidate any cookies

I changed my HTTP adapter class to expose the underlying 'cachePolicy', and to then contain the following code when constructing new instances of NSURLRequest:

NSMutableURLRequest *req;
req = [NSMutableURLRequest requestWithURL:url
                              cachePolicy:cachePolicy
                          timeoutInterval:60.0];

if (cachePolicy == NSURLRequestReloadIgnoringCacheData) {
    [req setHTTPShouldHandleCookies:NO];
}

This solution is a bit of a stopgap-- the only time I ever need to ignore the cache is when the user credentials change while the application is running. Every other caller of this class expects the default cache policy. And this "fix" has more to do with the behavior of the existing website I access (and its use of cookies) than NSURLRequest per se.

In short, there is good news and bad news. The good news is that it works. The bad news is that I am still not completely happy about the solution. The only silver lining here is that the implementation did not involve too much hand waving, and should be easy to remove once I find a better way.

While it is good to know that one can disable cookie support on a request-by-request basis, I will probably take the next step and model the user credentials in a way that makes this type of behavior transparent to all other kinds of HTTP requests.

iphone/mobile

Comments: 2 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Thank you! This helped me figure out something that was driving me insane!

   Comment by Workshed, Sunday, May 3, 2009 @ 6:16 am

2. 

   If I’d sell my application, I’d give 20% of my earnings to you.. Unfortunately, it’ll be free Thanks a lot man. Please keep writing

   Comment by Jim, Tuesday, May 5, 2009 @ 5:48 pm

Leave a comment