Consider the possibility that you're actually getting an
HTTP 4xx error and misdiagnosing it as a 5xx one.
Think hard and see whether it's a temporary
404 or something more serious like a
403 (or god forbid, a
410). Check carefully to see whether it's a subtle
401 error, and if so what the embedded challenge is that you're not satisfying (hint: these are often hidden in metadata like the HTTP headers, so they're easy for a naive developer to miss).
It's also worth considering server load - it's not uncommon to get a
409 or
423 response if the server is overloaded, especially if you've already forked one or more child processes that the server is using most of its cycles dealing with. Importantly, excessive polling can in turn cause
429 errors, so be careful to set your retry delay appropriately with some sort of exponential back-off.
You said this is a wife, so hopefully the problem isn't
402, but depending on your respective tastes it might be a
405 or
406 error, especially depending what you're trying to PUT and where. Perhaps it might be worth double-checking or relaxing your Accept header requirements and trying another round of content-negotiation? Counter-intuitively, this might even work for a
413 (which, while gratifying, can still be a problem if you're making requests to a server prone to suffering
507 issues).
If you carefully debug all these issues and determine it's definitely a 5xx error, it might be worth carefully debugging the server - a
503 may spontaneously resolve on its own, but other issues may require some sort of outside intervention, or (if the issue is serious enough, and you can't live without a response),
potentially even severing the connection and attempting to request from other backup servers.
More realistically though this is almost always a solvable problem - sometimes it resolves on its own, but other times it needs some input from the client... and it's very, very easy to send a malformed or ill-timed request and trigger further server issues so it's worth debugging as delicately as possible. Consider setting up a local cache on localhost that serves mock data, so you can serve your own responses while you wait for the situation to be resolved.
Remember, when you debug and can't find the problem, most of the time it's an assumption of
yours that isn't true, so try not to assume anything, and instead watch the output carefully to try to work out what the problem is.
Good luck, and hopefully you'll be back to successfully exchanging packets with the server on a regular basis soon.
I could totally see myself using one for maybe a month, tops.
@ payload too large
