There is an ongoing issue with the apparent lack of response when HTTP connections fail, such as with invalid URLs (issue #1937).
PR #1939 was a simple attempt to address this problem, but I'm closing that because this issue requires scoping out properly first and applies to all types of TCP connections, not just HTTP.
When a HTTP request is issued a completed delgate is supplied, which receives a boolean successful parameter. This parameter is false if HTTP parsing fails or the remote connection returns an HTTP error code.
If, when sending the request, a failure occurs in the connection process then the callback is never invoked. This can happen if:
- The server address specified cannot be resolved (DNS failure)
- A TCP connection cannot be made to the server (no service on the specified port)
And probabaly others. Issues are:
- These failures are essentially permanent so retrying the request is generally pointless, but that is what happen and can continue indefinitely
- Diagnosing the issue requires setting
DEBUG_VERBOSE_LEVEL=3 and observing output
- There's no mechanism for reporting these failures to an application
My feeling is that invoking the HttpRequest completion callback is not the correct approach here since a failure (successful=false) should only relate to the response from the remote server. Here, the request hasn't actually completed and is still in the queue.
This suggests that a new API for catching such errors would be useful for an application.
We'd need to:
- Decide where to place the API (probably in the TCP classes somewhere)
- How to define the callback, perhaps with a code indicating the cause of failure (e.g. DNS resolution failure)
- Fully document the various callbacks and methods to clarify usage
There is an ongoing issue with the apparent lack of response when HTTP connections fail, such as with invalid URLs (issue #1937).
PR #1939 was a simple attempt to address this problem, but I'm closing that because this issue requires scoping out properly first and applies to all types of TCP connections, not just HTTP.
When a HTTP request is issued a
completeddelgate is supplied, which receives a booleansuccessfulparameter. This parameter is false if HTTP parsing fails or the remote connection returns an HTTP error code.If, when sending the request, a failure occurs in the connection process then the callback is never invoked. This can happen if:
And probabaly others. Issues are:
DEBUG_VERBOSE_LEVEL=3and observing outputMy feeling is that invoking the HttpRequest completion callback is not the correct approach here since a failure (
successful=false) should only relate to the response from the remote server. Here, the request hasn't actually completed and is still in the queue.This suggests that a new API for catching such errors would be useful for an application.
We'd need to: