DO NOT REPLY [Bug 14036] New: - MultipartPostMethod does not check for error messages

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14036>.
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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>