NSURLSession loses cookies on redirect using the Background configuration

NSURLSession seems to ignores cookies when following a redirect when configured with backgroundSessionConfigurationWithIdentifier().


I have tested this on iOS 8.4 and iOS 9.3.


Has anybody else seen this behaviour?


My use of NSURLSession works fine when using the defaultSessionConfiguration(), but fails to store a authentication cookie that is delivered as part of a redirect when configured with the background. The cookie has the Secure flag set, and is delivered as part of a HTTPS session.


As I said, the code does work with the default config but fails using the background configuration. This is true when the iOS app is in the foreground or the background.


The docs state that redirects in the background are followed automatically without waking the app. Could this part of iOS be forgetting to read the Headers for cookies?


Any ideas??

Accepted Reply

Has anybody else seen this behaviour?

Yes. This is a known bug (r. 16,852,027).

In many cases it’s possible to work around this but the best way of doing that depends on your specific circumstances. For example, one option is to use a standard session to run the initial request, not follow the redirect, grab the cookies from the redirect response, and then issue a request in the background session for the target URL with those cookies.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Replies

Has anybody else seen this behaviour?

Yes. This is a known bug (r. 16,852,027).

In many cases it’s possible to work around this but the best way of doing that depends on your specific circumstances. For example, one option is to use a standard session to run the initial request, not follow the redirect, grab the cookies from the redirect response, and then issue a request in the background session for the target URL with those cookies.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks Eskimo, that is a good solution.

What issues would I face if I just use the default configuration for all the session requests whilst the app is in the background?

The docs are not forthcoming with the downsides of using the default session whilst backgrounded.


Is it possible for me to access the details of that radar bug? The link posted contains the URL of this thread.


Many thanks,

Andy.


EDIT: All the downloads the app is considering would be 50-70KB in size. Very quick.

What issues would I face if I just use the default configuration for all the session requests whilst the app is in the background?

If you can guarantee that the requests will complete before you app gets suspended, it’s fine to use a standard session while your app is in the background. OTOH, if requests are running in a standard session when your app gets suspended, those requests will fail in an ugly way.

So, the problem is guaranteeing background execution time. If you’re running in the background for other reasons (you’re an audio app, for example), you can just go to town. If not, you can use a UIApplication background task to get yourself some extra execution time, but that’s very limited.

There’s certainly nothing stopping you using a hybrid approach. For example:

  • You could use a standard session for ‘small’ requests and a background session for ‘big’ requests.

  • You could use a standard session for all requests and, if you run out of background execution time, cancel the requests and resume them in a background session.

EDIT: All the downloads the app is considering would be 50-70KB in size. Very quick.

On some networks that will be fast; on the very edge of a GPRS network, it will not be.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"