HttpClient 4 supports expect-continue, right? If so, there doesn't seem to be any need to make it work another way.
Sam On Mon, Mar 30, 2009 at 10:26 AM, Oleg Kalnichevski <[email protected]>wrote: > 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] > >
