Sam Berlin wrote:
"handled correctly" in this case means that everything continues as normal,
except because the entity cannot be repeated, the second request fails? If
so, the patch looks good.
I wonder, though, if it's possible to improve this behavior. I haven't
looked into the details of what is actually being exchanged, but I would
think that the authentication can happen (and fail) before the entity is
sent the first time, so the subsequent (correct) authentication doesn't need
to "repeat" the entity -- it can just send it as if it were the first time.
The proper way of solving the problem is by using the 'expect-continue'
handshaking. This way the request body will not have to be sent unless
authentication is successful. With 'expect-continue' disabled or broken
I am afraid there is not much we can do. Feel free to investigate
further, though.
Cheers
Oleg
Sam
On Mon, Mar 30, 2009 at 8:38 AM, Oleg Kalnichevski <[email protected]> wrote:
Oleg Kalnichevski wrote:
Sam Berlin wrote:
I just committed a small patch (
http://svn.apache.org/viewvc?view=rev&revision=758447 ) to include the
cause, but could not find what you were referring to about
authentication failures.
Hi Sam
It looks like HttpClient 4.0 _may_ be no longer able to correctly handle
authentication failures with non-repeatable requests, which is a regression
from 3.x. I am in the process of writing test cases for testing the most
essential authentication functionality.
I was wrong. Authentication failures with non-repeatable requests are
handled correctly. Added a test case. Please review.
Oleg
The patch looks innocuous enough, but if you
could glance at it, that would be appreciated.
Looks good to me.
Oleg
Sam
On Wed, Mar 25, 2009 at 3:25 PM, Oleg Kalnichevski <[email protected]>
wrote:
Sam Berlin wrote:
It might help with debugging arbitrary NonRepeatableRequestExceptions
if it somehow captured the original exception that triggered the retry
and added it to the cause. Think this has any merit (or is it even
possible with the current code structure)?
Yes, it does and it should be feasible with the current code
structure.
However, the most likely cause of request retries are authentication
failures, which are not signaled by an exception. So, it is not entirely
clear what to do about authentication failures.
Anyone would be interested to look into that?
Oleg
Sam
On Tue, Mar 24, 2009 at 9:37 AM, Oleg Kalnichevski <[email protected]>
wrote:
On Tue, 2009-03-24 at 08:51 +0530, Subhash Chandran wrote:
We are getting this Exception:
<quote>
Exception in thread "main"
org.apache.http.client.ClientProtocolException
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:557)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)
at it.sella.iq.Main.main(Main.java:63)
Caused by: org.apache.http.client.NonRepeatableRequestException:
Cannot retry request with a non-repeatable request entity
at
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:402)
at
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
... 3 more
</quote>
when we are trying to send Multi-part messages like this:
<quote>
File f = ...;
DefaultHttpClient httpclient = new DefaultHttpClient();
MultipartEntity entity = new MultipartEntity();
entity.addPart("file", new InputStreamBody(new FileInputStream(f),
f.getName()));
</quote>
We tried adding:
<quote>
httpclient.setHttpRequestRetryHandler(new
DefaultHttpRequestRetryHandler(0, false));
</quote>
This also does not help. How do we fix this?
Additional Info: when we are using FileBody instead of
InputStreamBody, the code is working fine.
This exception makes perfect sense. FileBody is repeatable, as a
File
can be read from multiple times. InputStreamBody is not repeatable,
because an InputStream can be read from only once.
You basically have two options: (1) use repeatable ContentBody
implementations only or (2) make sure the request does not need to be
retried. Please note the latter is not always possible. Request
retries
due to authentication failures can be avoided, but those due to I/O
errors cannot.
Hope this helps.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
