hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1684) 100-Continue support broken
Date Tue, 08 Sep 2015 08:13:45 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734403#comment-14734403

Oleg Kalnichevski commented on HTTPCLIENT-1684:

You assertion that a final response during an expect-continue handshake somehow cancels Content-Length
delineated body stream but for some reason does not cancel chunk coded content stream sounds
illogical, inconsistent and not substantiated by any requirements of the RFC 2616. 

The expect-continue handshake defines a means to avoid sending content body, _any bit of it_,
if the server is going to reject it anyway. A final response during to a request with 'expect:
continue' leaves the connection in a consistent and re-usable state (unless explicitly stated
otherwise with 'Connection: close'). In case of a race condition when both the client sends
the request body and the server responding with a final status the client is expected to handle
it as any out of sequence response: stop sending content, process the response message and
terminate the connection. It is simple and consistent.

You are welcome to dislike me, HttpClient and use whatever other HTTP library that suits your
needs better. Having said all that, I will once again review RFC 7230 and RFC 7231 and if
I find anything I have overlooked previously regarding the expect-continue handshake I'll
re-open the issue and provide a fix. Based on the requirements of the RFC 2616 alone I am
still of opinion the issue is invalid.


> 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, 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 not entirely correct because
the HTTP specs requires the *client* to close the connection not the server).

This message was sent by Atlassian JIRA

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

View raw message