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]
