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]

Reply via email to