Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Mon, 7 Sep 2015 12:56:45 +0000 (UTC)
From: =?utf-8?Q?Piotr_Ko=C5=82aczkowski_=28JIRA=29?= <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12862210.1441629418000.272411.1441630605660@Atlassian.JIRA>
In-Reply-To: <JIRA.12862210.1441629418000@Atlassian.JIRA>
References: <JIRA.12862210.1441629418000@Atlassian.JIRA>
 <JIRA.12862210.1441629418526@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1684) 100-Continue support broken
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1684?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D14733659#comment-14733659 ]=20

Piotr Ko=C5=82aczkowski commented on HTTPCLIENT-1684:
------------------------------------------------

You're not alone - had a similar bug as well:
http://curl.haxx.se/mail/lib-2004-08/0002.html


> 100-Continue support broken
> ---------------------------
>
>                 Key: HTTPCLIENT-1684
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-168=
4
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.5
>         Environment: Linux Mint 17.2, Oracle Java 8 u60
>            Reporter: Piotr Ko=C5=82aczkowski
>
> 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=20
> 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 encodin=
g.
> {quote}
> 8.2.2 Monitoring Connections for Error Status Messages
> An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the n=
etwork connection for an error status while it is transmitting the request.=
 If the client sees an error status, it SHOULD immediately cease transmitti=
ng 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 heade=
r, the client MUST close the connection.=20
> {quote}
> The problem is that HttpClient does *not* send the last chunk in this cas=
e, 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 c=
onnection open. This breaks subsequent requests on this connection, since a=
 standard-compliant server would expect the request body and would interpre=
t any subsequent HTTP status line as an entity chunk instead of a new reque=
st.
> 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 i=
s not entirely correct because the HTTP specs requires the *client* to clos=
e the connection not the server).


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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org