[
https://issues.apache.org/jira/browse/HTTPCLIENT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski reopened HTTPCLIENT-1684:
-------------------------------------------
> 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
> Fix For: 5.0
>
>
> 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, nor continues sending the body which are the
> only options allowed by the specs. 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 subsequent 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 a
> safe, but suboptimal default.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
