Re: Problems with authenticated background downloads involving a 301 redirect
Re: Problems with authenticated background downloads involving a 301 redirect
- Subject: Re: Problems with authenticated background downloads involving a 301 redirect
- From: Scott Hancher <email@hidden>
- Date: Wed, 23 Jul 2014 13:56:53 -0700
This took some time to figure out how to decipher the initial request and redirected request. I did manage to get Charles Proxy to decipher the data for me, but it didn't work until I pulled this line:
_configuration.TLSMinimumSupportedProtocol = kTLSProtocol12;
With this line in place I kept getting an SSLHandshake failed problem.
Now that I can trace the requests, I've determined that this is NOT specific to background downloads. Within the initial request, we add an 'Authorization' header to the request. When our server redirects via a 301, the subsequent redirected request does not include this 'Authorization' header. I added an innocuous foo:bar header just to see if all headers were getting stripped, but foo:bar survived the redirect. This was working for foreground downloads, because we implement the delegate method, URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler: and carry over the 'Authorization' header from the original to the redirected request. We have no such facility to do so for background downloads.
Is this a known issue? What do you suggest?
++Scott.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden