> This problem seems like it is the perfect candidate for the
> ExpectContinueMethod.setUseExpectHeader() function. Isn't this exactly
> the scenario for which this header was intended?
True. The catch is that some HTTP servers do not adequately support 'expect-continue'
handshake, which is exactly the trouble Siddhartha's is having.
Oleg
Oleg Kalnichevski wrote:
>Siddhartha,
>
>I believe the solution to this problem is trivial. All it takes is
>checking for availability of a response from the target server prior to
>sending each consecutive chunk of request body. A premature response
>from the target server detected before the request body has been
>transmitted in its entirety most likely signifies a problem (such as
>authentication failure), which should cause the request to be aborted
>and the connection force-closed once the response is read.
>
>I'll happily provide a fix for this problem, but currently there are
>more pressing issues that must be addressed first. Besides, it is
>already too late to incorporate the fix into 2.0 release, so it will
>have to wait until next release (2.1). You are welcome to work on a
>patch, if you feel like to, or you can wait until the problem makes it
>to the top of our priority list (which may take a while) to be fixed in
>its due time
>
>Cheers
>
>Oleg
>
>On Sat, 2004-01-03 at 21:34, Sid Subr wrote:
>
>
>>from looking at the filepart code seems that this part
>>would be creating a problem which makes the code not
>>recoverable from the server closing the connection
>>when authentication fails...
>>Filepart.java for httpclient
>>
>>sendData(){
>>
>>create a new byte array of size 4K
>>
>>while thereis stuff to be read from the file send it
>>out to the outputstream
>>
>>finally close the stream
>>
>>}
>>
>>I know the while loop is the one that chokes when the
>>connection is closed as the httpclient has not yet
>>finished writing the whole file (the release
>>connection is also not called which might help in teh
>>retry)and the IOException from that write is sent all
>>the way up and since it is not an
>>HttpRecoverableException the whole thing does not even
>>go to the point of trying to send it out the next time
>>with credentials.. how do you propose to change this?
>>The only way I see is to send part of the file to the
>>server and when the challenge comes and the connection
>>is closed start sending the file in parts and hope it
>>will not get challenged.. otherwise we might be stuck
>>in the sending (a max of three times specified in the
>>MethodRetryHandler) ..
>>
>>any input would be helpful..
>>
>>Sid
>>
>>__________________________________
>>Do you Yahoo!?
>>Protect your identity with Yahoo! Mail AddressGuard
>>http://antispam.yahoo.com/whatsnewfree
>>
>>---------------------------------------------------------------------
>>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]
