iOS/Foundation URLSession upload infinite-loops

Question

I'm first going to ask this without full listings and logs because it feels like the sort of thing that people might recognize generically from their own work.

iOS 16 simulator, Xcode 14.2.

Aim

I want to upload a file to a REST server. I'm using URLSessionUploadTask. HTTP Basic authentication goes through (by the low-level fact that once I provide basic creds, URLSession stops asking).

I can assume that the bytes are getting there: My task delegate's urlSession(_:task:didSendBodyData:... is called with the right number of bytes, and equal to the expected number of bytes. I assume that's not a count of what was cast into the net, but the product of some client/server acknowledgment.

The minor odd thing is that I see in my logs is first the server-trust auth challenge, then the did-send, and only then HTTPBasic.

∞ Loop

The major odd thing is:

didReceive challenge: NSURLAuthenticationMethodServerTrust
didSend: 296 / 296
didReceive challenge: NSURLAuthenticationMethodHTTPBasic
didReceive challenge: NSURLAuthenticationMethodServerTrust
didSend: 592 / 592
didReceive challenge: NSURLAuthenticationMethodHTTPBasic

... and so on, ad infinitum, accumulating by multiples of the total data. I admit I have not checked the arithmetic on payload size, I suspect that the count is not necessarily common-sensical. If you have some experience to which the counts are critical, I'm glad to hear from you.

The delegate methods for end-of-transfer, success or failure, are never called. The closure argument for URLSession.shared.dataTask... is never called.

The server's listing page does not show the file present.

Supplement: Multipart

Content-Type: multipart/form-data; boundary=593FBDC3-7A99-415D-B6B4-3F553CB6C9C2
--Boundary-593FBDC3-7A99-415D-B6B4-3F553CB6C9C2
Content-Disposition: form-data; name="file"; filename="InputSample.zip"
Content-Type: application/zip

0123456
--Boundary-593FBDC3-7A99-415D-B6B4-3F553CB6C9C2--

The linebreaks I intend are \r\n, per the general standard. "0123456" is a part of this package as Data containing that string. I wonder if the promise of .zip content without actual .zip-formatted data is a problem. I hadn't thought J. Random Apache would be that "helpful."

Oh, and:

My upload task calls .resume() once and only once. Instruments shows no hotspot or deep stack in my code, which I'd expect in a coded infinite loop.

Answer 1

In terms of why you are seeing a request retried, that is a product of an authentication challenge system. When we receive a challenge, we provide authentication credentials, and URLSession will automatically retry the request with the supplied credentials. It will do this with every authentication challenge, unless we explicitly tell it to cancel.

So, that having been said, I have two observations:

• Given the ping-ponging between different NSURLAuthenticationMethod values, I suspect there is likely a disconnect between what authentication system the client challenge handler prepared and what the server requested.
• The infinite loop is likely a result of the client challenge handler not disambiguating between an initial challenge (in which case you should supply the credentials) and the server rejecting the previously supplied credentials (in which case you should just cancel and report the error in the UI).

To answer this definitively, we would need to see:

• the client authentication challenge handler code; and
• details about which type of authentication has actually been set up on your server.

But one could easily end up with the pattern you describe if the client ignores the specific authentication type being requested (presumably not “basic”), but proceeds to supply “basic” authentication credentials nonetheless.

Make sure the client’s challenge handler is looking at the protectionSpace, identifying what sort of challenge it is receiving, and that it prepares an authentication response of the appropriate authentication scheme.

Also, you will want to differentiate between a challenge that is requesting credentials for authentication (the first time the delegate method is called) and an authentication that failed (a second, subsequent call to the delegate method). We should provide credentials in response to the former, but cancel in the case of the latter.

See Handling an Authentication Challenge.