…ssion was unable to create a task
… in order to catch invalid constructions early
…to write bytes
…ageWithURL:, et al.
…BackgroundURLSession: This should not happen because sometimes this method is called after waking the app up to respond to authentication challenges and no tasks have completed yet. It is not safe to assume that all tasks are complete and the delegates should be removed. Doing some results in orphaned tasks with AF delegates to handle them. Task delegates already get deleted after the URLSession:task:didCompleteWithError: call which will be made for each task. Issue: 1579
… rather than AFHTTPSessionManager
…uaranteed and no longer breaks AFNetworkActivityIndicatorManager
…onManager if the `manager` method uses the current class type instead of a hardcoded one
appropriate error on the NSOperation. There is a race condition where 'cancel' is called immediately after 'start'. When operationDidStart is then called on the Network Thread, self.connection is not instantiated, because the NSOperation is cancelled, and 'finish' is called, but without the error set. When cancelConnection is then called on the Network Thread, the error is not set, because the operation is already finished. In the new code, cancelConnection is always responsible for setting the error, and then calling 'finish'. operationDidStart never attempts to call 'finish'. This bug was one of the sources of non-deterministic failures in testThatCancellationOfRequestOperationInvokesFailureCompletionBlock.
the state of AFURLConnectionOperation, causing the Network Thread to enter an infinite loop. The logic for 'pause' was calling [self.connection performSelector:...]. If 'pause' is executed immediately after 'start', and 'start' did not have a chance to create self.connection on the Network Thread, then the logic in 'pause' would effectively be a no-op. When 'resume' gets called, the previous connection was not actually cancelled, so there are 2 connections both of which have a reference to the same NSOutputStream. The first connection to finish/error would close the NSOutputStream, and the second connection would spin forever in the delegate callback connection:didReceiveData: since [self.outputStream hasSpaceAvailable] always returns NO. The test case I added reproduces the failure, but is flaky because it relies on a race condition between the main thread and the Network Thread.