[TIMOB-1893] XHR call fails after network switching
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Invalid |
| Resolution Date | 2011-04-15T03:04:54.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 |
| Components | iOS |
| Labels | defect, ios, iphone, rplist, xhr |
| Reporter | ctredway |
| Assignee | Blain Hamon |
| Created | 2011-04-15T03:04:53.000+0000 |
| Updated | 2017-03-02T19:32:23.000+0000 |
Description
on iOS 3 & iOS 4 when the device switches from wifi to cellular or vice versa the xhr call errors.
see this ticket.
http://developer.appcelerator.com/helpdesk/view/43581">http://developer.appcelerator.com/helpdesk/view/43581
Comments
- Stephen Tramer 2011-04-15
There is a very good reason why this behaves the way it does, and the behavior is "correct" and something we have no control over as it happens at the system and hardware level.
WiFi (en0) and data (some other device, I forget) are different interfaces. Say that we have an HTTP request which starts on en0, which is then terminated. This means that the connection to the actual hardware interface has been terminated, which SHOULD be a cancel error. In addition, sometimes hardware is very bad about reporting its status as having the network terminated. In particular, there's the following scenario:
- An HTTP request goes through on WiFi and negotiations are started
- WHILE the request is being processed, WiFi goes down
- But since the request has "completed", timeout doesn't take effect - instead we wait for the response for an indeterminate amount of time
Here is what the user should do instead.
- Watch for reachability changes on their own
- When reachability changes, CANCEL AND RESTART any outgoing HTTP requests
Remember: When using HTTP, you are responsible for managing all of your connection information, up to and including monitoring for reachability changes.
- Lee Morris 2017-03-02 Closed as invalid.