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 Tue, 08 Sep 2015 17:43:47 GMT

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

Piotr Kołaczkowski edited comment on HTTPCLIENT-1684 at 9/8/15 5:43 PM:
------------------------------------------------------------------------

I asked guys on the http-wg mailing list about this and I've got the response from Roy T Fielding
(the co-founder of Apache HTTP project):

{quote}
> Hello Guys,
>
> In HTTP/1.1, if the server gets a request with "Expect: 100-Continue" and, after validation
of the head of the message, it decides to respond with an error status code (e.g. 4xx or 5xx)
but it doesn't close the connection, what state should it transition to? Should it wait for
the rest of the body (and discard it) or should it immediately reset back to the initial state
and wait for the next request in the sequence?
>
> Also, on the client side - when the client receives a final response instead of status
100 and decides not to close the connection, can it immediately jump to sending the next request,
or does it have to send the remaining body?
>
> One of the requirement says:
>
> "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"
>
>
> which pushes me toward thinking that after sending the final status code, if the server
does not close the connection, the server would be still waiting for the rest of the request
(to be discarded), and must not move on to processing the next request on the same connection
until it gets the end of the body (last chunk or all content-length bytes). Is it a correct
interpretation?

Yes. Either side can choose to close the connection, but the server can't see another request
until it has read past the framing of the first request. Most servers choose to close the
connection if the response is non-2xx because 100-continue is meant to abort the send when
it is unwanted.

....Roy
{quote}
https://lists.w3.org/Archives/Public/ietf-http-wg/2015JulSep/0324.html

Please mark this ticket as either Reopened or Won't fix, but not Invalid. 
The simplest way to fix it would be probably just always closing the connection on any non-100,
non-200 response.


was (Author: pkolaczk):
I asked guys on the http-wg mailing list about this and I've got the response from Roy T Fielding
(the co-founder of Apache HTTP project):

{quote}
> Hello Guys,
>
> In HTTP/1.1, if the server gets a request with "Expect: 100-Continue" and, after validation
of the head of the message, it decides to respond with an error status code (e.g. 4xx or 5xx)
but it doesn't close the connection, what state should it transition to? Should it wait for
the rest of the body (and discard it) or should it immediately reset back to the initial state
and wait for the next request in the sequence?
>
> Also, on the client side - when the client receives a final response instead of status
100 and decides not to close the connection, can it immediately jump to sending the next request,
or does it have to send the remaining body?
>
> One of the requirement says:
>
> "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"
>
>
> which pushes me toward thinking that after sending the final status code, if the server
does not close the connection, the server would be still waiting for the rest of the request
(to be discarded), and must not move on to processing the next request on the same connection
until it gets the end of the body (last chunk or all content-length bytes). Is it a correct
interpretation?

Yes. Either side can choose to close the connection, but the server can't see another request
until it has read past the framing of the first request. Most servers choose to close the
connection if the response is non-2xx because 100-continue is meant to abort the send when
it is unwanted.

....Roy
{quote}

Please mark this ticket as either Reopened or Won't fix, but not Invalid. 
The simplest way to fix it would be probably just always closing the connection on any non-100,
non-200 response.

> 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