hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Piotr Kołaczkowski (JIRA) <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1684) 100-Continue support broken
Date Tue, 08 Sep 2015 14:28:46 GMT

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

Piotr Kołaczkowski commented on HTTPCLIENT-1684:
------------------------------------------------

I tried to reach out to the "source of truth" about HTTP, that is the HTTP working group mailing
list and found this email from Adrien de Croy:

{quote}
In the end, I think that's the biggest problem with Expects - people 
expect (pardon the pun) more from it than it delivers.  The reason the 
history of this list contains numerous discussions about Expects, is 
because of common misinterpretation.

The wording in the RFC implies that Expects and 100 Continue can be used 
to avoid sending the body of a request.  It omits to mention that if 
indeed you do want to avoid this (e.g. when you get a 3xx or 4xx), you 
either need to disconnect and re-try, or complete the message some other 
way (e.g. use chunking and prematurely complete it with a 0 chunk).
{quote}

https://lists.w3.org/Archives/Public/ietf-http-wg/2010JanMar/0353.html

Noone opposed, so I guess he was right.

> 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 a safe, but suboptimal default.



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


Mime
View raw message