Search code examples
ioscurlnsmutableurlrequest

Connect and Complete timeouts for NSMutableURLRequest


We're converting our CURL HTTP Get requests to native IOS code. With CURL we can set two different timeouts - CURLOPT_CONNECTTIMEOUT - how long before a call fails if it cant connect, and CURLOPT_TIMEOUT - how long before a call fails if all the data hasnt been retrieved. If the connect fails we want it to return pretty quickly (10 seconds), but we download large chunks of data possibly on slow connections so we need the completion timeout to be quite large (5 minutes).

How do we set different timeouts using NSMutableURLRequest

Currently we are setting the single timeout like this

[urlRequest setTimeoutInterval:30.0f]

Is there a way to set two separate timeouts, like CURL does ? And which timeout are we currently setting ? The connection timeout or the completion one.

Thanks

shaun


Solution

  • That's a really good question. The documentation on it was unclear to me:

    If during a connection attempt the request remains idle for longer than the timeout interval, the request is considered to have timed out. The default timeout interval is 60 seconds.

    I did find this really helpful post in the Apple Developer Forums, which an Apple employee explains:

    The timeoutInterval property is equivalent to timeoutIntervalForRequest property.

    He's referencing the property on NSURLSessionConfiguration, which can be attached to an NSURLSession. If you set the timeoutInterval of an NSURLRequest, it is used as the value for timeoutIntervalForRequest on the configuration. This property's documentation does provide some insight:

    The request timeout interval controls how long (in seconds) a task should wait for additional data to arrive before giving up. The timer associated with this value is reset whenever new data arrives. When the request timer reaches the specified interval without receiving any new data, it triggers a timeout.

    The default value is 60.

    Based on that, it seems this value is actually neither!