Hi Tim, See my comments in-line below
> I'm using HttpClient in an application to initial ACH checking transfers > with a bank. I need to make a GET request, but I had questions about > the HttpRecoverableException. > > When is that thrown during the communications timeline? > Rather unfortunately exception handling in HttpClient 2.0 got quite messy. There's no easy way of telling under what circumstances HttpRecoverableException can be thrown. In most cases all transport errors are re-thrown as recoverable exceptions, but there are situations when they are not. Frankly, those applications that require idempotent HTTP methods must disable automatic recovery by providing a custom MethodRetryHandler and simply treat all HttpRecoverableException as fatal transport exceptions Exception handling in HttpClient HEAD (pre 3.0-alpha) has undergone a significant overhaul. Things have got much simpler and cleaner HttpRecoverableException is thrown when (1) an I/O error occurs while sending the request to the target server AND the connection is known to be good (there has been at least one successful write operation) (2) the target fails to send a response (no status line is found or connection is simply dropped before the status line has been generated) (3) socket or connection timeout I/O errors when reading response are NEVER re-thrown as recoverable exceptions > My challenge is that the bank processes each GET request, even if it has > the same parameters as a previous request (yes, I know that GETs should > be idempotent but I don't have a choice). I can't charge people twice. > I want to retry the request, though, if I know that the bank hasn't > received it (DNS failure, connection refused, connection timeout), but I > CAN'T retry it if they MAY have received the request (e.g. response read > timeout, 500 error, etc.). > HttpRecoverableException represents a recoverable transport exception. Protocol exceptions represent non-recoverable errors per definition and are never reported as HttpRecoverableException. > I obviously want to err on the cautious side. But I wondered if the > Exception handling in the HttpClient makes any distinction between > errors that occur before the server has (possibly) read the request, and > those that occur afterwards. > Both HttpClient 2.0 and 3.0-dev do make such a distinction. Have a look at MethodRetryHandler interface. There's a requestSent flag which is set to true when the recoverable exception occurs after the request has been transmitted to the target server > I'm a (relative) novice at the finer points of HTTP. Any hints you have > to help me retry when possible and simultaneously avoid duplicate > submissions would be great. > The main problem with HTTP protocol that it has never been envisaged to be used in any sort of transactional applications. Initially HTTP has been designed as a stateless, request/response oriented protocol intended to retrieve simple static content. With the original purpose in mind request duplication has never been thought of as an issue. These inherent limitations of HTTP make it ill-suited for applications where sequence of requests is important or request duplication is not permissible. The problem you are having should better be addressed at the application level, not at the transport level. Hope this sounds not too discouraging Cheers, Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
