5 ms·
Assume it only queries your server. Assume your server will only ever meaningfully return 200. Assume the method has no reason to ever move (so no 301 redirec
by Groxx 13y ago
Assume it only queries your server. Assume your server will only ever meaningfully return 200. Assume the method has no reason to ever move (so no 301 redirect (edit: and redirects are generally handled by your request library anyway)). Assume the only time it should fail is if your server falls over on itself, which should be temporary.
What else would you do then? These are not crazy expectations. Exponential backoff might be reasonable, but I'd argue that's part of "else{retry}" since it's inherently retrying.
- derefr 13y ago> These are not crazy expectations. Sure they are. Choosing to communicate over HTTP means allowing for the presence of proxies between "your" client and "your" server. In HTTP, you don't control the whole path, even if you control both sides.
- Groxx 13y agoProxies are also fuzzy. I assume you're referring to e.g. a 407 or 511 error? Many times they're handled by something between you and the network library, often the operating system. Sometimes they're not handled at all at the system level (hooray, Android (until recent versions)!), so if you didn't put a proxy in there, you don't have one. VPNs can also exist, but they sometimes send custom error status codes[1]. How do you handle those? Retry if `code % 3 == 1`? Will your program even be informed if the VPN connection is restored, or will you have to just blindly retry until it works? [1]: http://compnetworking.about.com/od/vpnsetup/tp/common-vpn-error-codes-explained.htm http://compnetworking.about.com/od/vpnsetup/tp/common-vpn-er...