[
https://issues.apache.org/jira/browse/HTTPCLIENT-1684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14734003#comment-14734003
]
Piotr Kołaczkowski edited comment on HTTPCLIENT-1684 at 9/7/15 7:13 PM:
------------------------------------------------------------------------
Have you read the discussion I linked about libcurl? Libcurl also got it wrong,
but they realized it and fixed.
Yes, the server is perfectly able to reject. It is allowed to close the
connection. Also, the client is allowed to close the connection. The client is
also allowed to shorten the entity by skipping all the chunks except the last
one, because it knows the entity will be discarded. Works as designed.
If your interpretation of the protocol were correct, just answer the simple
question: if, after receiving early response (not HTTP 100), the client will
not send the entity and leaves the connection open, in which state should the
server be? Is it waiting for the next request, or is it reading the entity?
BTW: it is not just my interpretation of the protocol. Guys at Microsoft
interpreted it ok:
{quote}
That change was required due to a HTTP bug in libcurl: libcurl was
sending request headers with "Expect: 100-continue", and when a
non-100 error status was returned, it would send the next request
headers on the same connection _without_ sending the request body.
That's a HTTP implementation bug in libcurl, nothing to do with IIS6.
It was always wrong. IIS6 was the first server where this was
noticed, but it could break other servers too. {quote}
was (Author: pkolaczk):
Have you read the discussion I linked about libcurl? Libcurl also got it wrong,
but they realized it and fixed.
Yes, the server is perfectly able to reject. It is allowed to close the
connection. Also, the client is allowed to close the connection. The client is
also allowed to shorten the entity by skipping all the chunks except the last
one, because it knows the entity will be discarded. Works as designed.
If your interpretation of the protocol were correct, just answer the simple
question: if, after receiving early response (not HTTP 100), the client will
not send the entity and leaves the connection open, in which state should the
server be? Is it waiting for the next request, or is it reading the entity?
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
