Piotr Kołaczkowski created HTTPCLIENT-1684:
----------------------------------------------

             Summary: 100-Continue support broken
                 Key: HTTPCLIENT-1684
                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1684
             Project: HttpComponents HttpClient
          Issue Type: Bug
          Components: HttpClient
    Affects Versions: 4.5
         Environment: Linux Mint 17.2, Oracle Java 8 u60
            Reporter: Piotr Kołaczkowski


Handling of Expect: 100-Continue is partially broken.
After getting the Expect header, the server is allowed to:
1. respond with an HTTP 100 Continue status 
2. respond with HTTP 417 Expectation Failed status
3. respond with the final HTTP answer, typically an error.

Handling of situation 1. seems to work ok. I haven't checked the scenario 2. 
But scenario 3. is broken, at least when using chunked transfer encoding.

{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}

The problem is that HttpClient does *not* send the last chunk in this case, nor 
terminates the connection. Instead it just happily returns the response to the 
user and doesn't send anything to the server, keeping the connection open. This 
breaks subsequent requests on this connection, since a standard-compliant 
server would expect the request body (!) and would interpret any HTTP status 
line as an entity chunk instead of a new request.

Debugging this is unfortunately quite hard, since many of the servers got this 
wrong either and they just close the connection in this case (which is not 
entirely correct because the HTTP specs requires the *client* to close the 
connection not the server).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to