[
https://issues.apache.org/jira/browse/HTTPCORE-411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Kalnichevski moved HTTPCLIENT-1684 to HTTPCORE-411:
--------------------------------------------------------
Fix Version/s: (was: 5.0)
5.0-alpha1
Affects Version/s: (was: 4.5)
Component/s: (was: HttpClient)
HttpCore NIO
HttpCore
Workflow: classic default workflow (was: Default workflow,
editable Closed status)
Issue Type: Improvement (was: Bug)
Key: HTTPCORE-411 (was: HTTPCLIENT-1684)
Project: HttpComponents HttpCore (was: HttpComponents HttpClient)
> 100-Continue support broken
> ---------------------------
>
> Key: HTTPCORE-411
> URL: https://issues.apache.org/jira/browse/HTTPCORE-411
> Project: HttpComponents HttpCore
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Environment: Linux Mint 17.2, Oracle Java 8 u60
> Reporter: Piotr Kołaczkowski
> Priority: Minor
> Fix For: 5.0-alpha1
>
>
> 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]
