hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Recoverable error question
Date Sun, 25 Jan 2004 12:51:13 GMT
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

> 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

The problem you are having should better be addressed at the application
level, not at the transport level. 

Hope this sounds not too discouraging



To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

View raw message