RE: upload large files- Filepart
Odi, Can you give me more details as to why you think this may cause problems with HTTP pipelining? I am a bit skeptical, as the approach I outlined simply follows the recommendation of the HTTP spec: quote 8.2.2 Monitoring Connections for Error Status Messages An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a chunked encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection. /quote -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 10:12 To: Commons HttpClient Project Subject: Re: upload large files- Filepart 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 just want to note that this approach may interfere with a future implementation of HTTP pipelining. Odi - 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]
Re: upload large files- Filepart
Kalnichevski, Oleg wrote: Can you give me more details as to why you think this may cause problems with HTTP pipelining? It won't if done right :-) You just need to make sure that you are monitoring the response corresponding to the request and not any other response from previously pipelined requests. But this discussion is too early as we have no plans for pipelining until now. It will be allright. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: upload large files- Filepart
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?
-Eric
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]
RE: upload large files- Filepart
that is correct unfortunately I have had the
privilege to work on a webserver which is supposed
to be 1.1 compliant..
I am trying hard to get them to support the 100-expect
continue at the same time I want to see if I can get a
work around.. and hence the mails!!
--- Kalnichevski, Oleg
[EMAIL PROTECTED] wrote:
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]
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: upload large files- Filepart
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]
