Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 5967 invoked from network); 29 Oct 2002 05:27:58 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Oct 2002 05:27:58 -0000 Received: (qmail 10089 invoked by uid 97); 29 Oct 2002 05:28:57 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10073 invoked by uid 97); 29 Oct 2002 05:28:57 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10059 invoked by uid 50); 29 Oct 2002 05:28:56 -0000 Date: 29 Oct 2002 05:28:56 -0000 Message-ID: <20021029052856.10058.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 14036] New: - MultipartPostMethod does not check for error messages X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14036 MultipartPostMethod does not check for error messages Summary: MultipartPostMethod does not check for error messages Product: Commons Version: Nightly Builds Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: HttpClient AssignedTo: commons-dev@jakarta.apache.org ReportedBy: adrian@ephox.com If a MultipartPost request is sent to a server which requires authentication, the server may respond to the request with an unauthorized header and close the connection before all of the data is sent. HttpClient should monitor the incoming stream and cease transmitting the body if an error message is received (section 8.2.2 of rfc2616, see below). At the very least HttpClient should check for a response when catching the HttpRecoverableException and retrying. This probably should be done in HttpMethodBase so that we are in a known state when starting to retry the connection (ie: there isn't an existing response in the socket buffer to cause problems). Ideally, HttpClient should also implement the 100 (Continue) status as specified in section 8.2.3 of rfc2616. Finally, PostMethod should be tested to ensure that it does not exhibit this bug as well. ------------- 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. -- To unsubscribe, e-mail: For additional commands, e-mail: