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] [Comment Edited] (HTTPCLIENT-1684) 100-Continue support broken
Date Mon, 07 Sep 2015 19:25:45 GMT

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

Piotr Kołaczkowski edited comment on HTTPCLIENT-1684 at 9/7/15 7:25 PM:
------------------------------------------------------------------------

All right, if the server is to wait for the next request, how does it handle receiving the
part of the entity that could have been sent before the client received 100 Continue? 

The RFC explicitly allows the client to proceed with the entity, even if it doesn't receive
100 Continue:
{quote}
   Because of the presence of older implementations [...] when a
    client sends this header field "Expect: 100-continue" to an
    origin server (possibly via a proxy) from which it has never seen
    a 100 (Continue) status, the client SHOULD NOT wait for an
    indefinite period before sending the request body. 
{quote}

And here, the RFC explicitly states the server may close the connection or wait for the entity
and discard it:
{quote}
Upon receiving a request which includes an Expect request-header
        field with the "100-continue" expectation, an origin server MUST
        either respond with 100 (Continue) status and continue to read
        from the input stream, or respond with a final status code. The
        origin server MUST NOT wait for the request body before sending
        the 100 (Continue) response. >>>>> If it responds with a final status
        code, it MAY close the transport connection or it MAY continue
        to read and discard the rest of the request. <<<<< It MUST NOT
        perform the requested method if it returns a final status code.
{quote}



was (Author: pkolaczk):
All right, if the server is to wait for the next request, how does it handle receiving the
part of the entity that could have been sent before the client received 100 Continue? 

The RFC explicitly allows the client to proceed with the entity, even if it doesn't receive
100 Continue:
{quote}
   Because of the presence of older implementations [...] when a
    client sends this header field "Expect: 100-continue" to an
    origin server (possibly via a proxy) from which it has never seen
    a 100 (Continue) status, the client SHOULD NOT wait for an
    indefinite period before sending the request body. 
{quote}

And here, the RFC explicitly states the server must wait for the entity and discard it:
{quote}
Upon receiving a request which includes an Expect request-header
        field with the "100-continue" expectation, an origin server MUST
        either respond with 100 (Continue) status and continue to read
        from the input stream, or respond with a final status code. The
        origin server MUST NOT wait for the request body before sending
        the 100 (Continue) response. >>>>> If it responds with a final status
        code, it MAY close the transport connection or it MAY continue
        to read and discard the rest of the request. <<<<< It MUST NOT
        perform the requested method if it returns a final status code.
{quote}

> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message