Timeout property for AFHTTPClient #576
Timeout property for AFHTTPClient #576
Conversation
Thanks for creating this patch, @vocaro. Following up from my previous response to a similar pull request a year ago, my advice now would be to override I understand the appeal of accessors for Since With timeout interval specifically, it's not clear when changing the timeout policy is actually the correct move: current network latency varies wildly depending on the kind of connection. Apple's policy, though heavy-handed at times, has been that we don't really know what timeout policies should be, and that our tendency to make it unreasonably short ends up being detrimental to users in dire circumstances. This is all to say that I need some time to think through this. Happy to hear any other opinions on the matter. |
I'm okay with rejecting this pull request for reasons of API simplicity. However, my concern is that it's not clear how to get around the problem. In the previous pull request #133, you suggested using AFHTTPRequestOperation as a means of setting the timeout. In this pull request, you're suggesting subclassing AFHTTPClient. Which is the appropriate solution? |
@vocaro Either works equally well. If you already have a subclass, just override the method, and everything happens automatically. For one-off instances of the client, use the aforementioned approach of manually creating and modifying the request, and passing that in to create and enqueue a new operation. |
I think a solution that would satisfy us both is some better documentation on how to handle this problem. I'll work on a pull request for that. In the meantime, could you please confirm that the correct way to rewrite this:
is this? (Note the addition of setTimeoutInterval).
Thanks! |
@vocaro Sorry for the belated response. Yes, that is the correct way to do that without a custom |
Okay, thanks. Please see related issue #632. |
This commit adds a
timeoutInterval
property toAFHTTPClient
. The typical use case is for servers that are sporadically slow to respond. For example, I send requests to a server that's usually fast but occasionally takes 45 seconds or longer to process a request. I don't want to keep the user hanging, thinking that the app is busy when in fact it's just stalled, waiting for a server that is taking forever to respond.I know that this issue has been discussed before, such as pull request #133. That request was rejected for two reasons:
It is not clear whether iOS honors the timeout
A timeout can be set with AFHTTPRequestOperation instead of AFHTTPClient.
For (1), I can say that I tested the timeout behavior (iOS 6) and it works just as expected. When a GET request takes longer than the specified timeout, AFHTTPClient fails with an error: "The request timed out."
As for (2), I would argue that the suggested workaround is unintuitive. It's not at all clear -- at least, not to myself nor the other two users who supported the earlier pull request -- that a timeout on AFHTTPClient can be set via AFHTTPRequestOperation. Furthermore, having to rewrite code to use AFHTTPRequestOperation is an unnecessary inconvenience for this seemingly common use case.
Thanks for reconsidering this issue.