Apple

Am 23.07.2014 um 22:56 schrieb Scott Hancher <email@hidden>:

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;

The TLS Protocol 1.2 is where forward secrecy comes into place. Hence its no surprise that decryption wont work anymore. But it depends on how which level Charles Proxy is proxying.

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?

Authentication always works the way that no authentication header is passed and the server rejects and asks for authentication with a 301.

This would pop up an authentication header in the browser.

If the original URL is redirected to a second URL, then the authentication realms might not be the same so OS X is correct in not sending authentication headers to the redirected server. If that server would not like the request and requests authentication, he answers with a 301 and then your URL would be resent with authentication. Authentication information can be held in cache for a specific realm and thus sent automatically but this is only valid in the same URL path. As you are redirecting from Server A to Server B, the cached authentication information for A is not valid for B.

So my answer would be that OS X is doing the correct behaviour. You could simply redo the URL to the redirected host directly.

++Scott.

On Mon, Jul 21, 2014 at 2:18 AM, Quinn "The Eskimo!" <email@hidden> wrote:

On 19 Jul 2014, at 00:23, Scott Hancher <email@hidden> wrote:

> I'm downloading files from our servers using an https scheme and an OAuth 2 'Authorization' header. The server receiving the request redirects via a 301 to a different URL for the actual file to download.
>
> The download works without issue if it's performed in the foreground (NSURLSession created with an NSURLSessionConfiguration created via [NSURLSessionConfiguration ephemeralSessionConfiguration]).
>
> However, if a background download is attempted (using [NSURLSessionConfiguration backgroundSessionConfiguration:] to construct the NSURLSessionConfiguration), then the download fails via a 403 status code.

Do you have any cookies involved? The one case I've seen similar to this involves NSURLSession background sessions not picking up cookies on the redirect <rdar://problem/16852027>.

If there are no cookies involved then I recommend you take a packet trace of the two requests (the one from the ephemeral session and the one from the background session) and see what's different, that is, what's causing the server to fail the request.

Share and Enjoy
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

_______________________________________________
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

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)

This email sent to email@hidden

Andreas Fink