[
https://issues.apache.org/jira/browse/HTTPCLIENT-886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12773475#action_12773475
]
Ortwin Glück commented on HTTPCLIENT-886:
-----------------------------------------
> In our case, this is very dangerous because the request has already been sent
> and is being processed by the back-end server.
If a repeated request is "very dangerous" you'd better implementing detection
for duplicate requests in your application! Use challenge/reponse tokens,
sequence numbers, timestamps or other means to detect repeated requests. The
behaviour of HttpClient is not the only source for repeated requests. Messaging
over any unreliable medium (like a network) ALWAYS has to make the choice
between either loosing some messages, or accepting and dealing with duplicates.
This is a fundamental theorem. It's the reason for why there is UDP and TCP and
their different guarantees.
If the client doesn't get a response it can never know whether the request
didn't reach the server or the response just didn't reach the client. By not
retrying the request, the client risks that the request never reached the
destination. It HAS TO retry the request until it gets a response. This
algorithm is called Idle-RQ and is used for TCP for instance.
> Incorrect handling of NoHttpResponseException in DefaultHttpMethodRetryHandler
> ------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-886
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-886
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Affects Versions: 3.1 Final
> Reporter: Sylvain Laurent
> Priority: Critical
> Fix For: 3.1.1
>
>
> We have a buggy load-balancer that sometimes forwards the request to the
> back-end server, and then close the connections without returning any data at
> all.
> This provokes a NoHttpResponseException inside commons http client 3.1, which
> is handled by DefaultHttpMethodRetryHandler.
> Unfortunately DefaultHttpMethodRetryHandler handles this
> NoHttpResponseException by asking for a retry. In our case, this is very
> dangerous because the request has already been sent and is being processed by
> the back-end server.
> I think that in the case of a NoHttpResponseException the test
> !method.isRequestSent() shoud be done :
> if (exception instanceof NoHttpResponseException &&
> !method.isRequestSent()) {
> // Retry if the server dropped connection on us AND the request
> was not sent
> return true;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
