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

ASF subversion and git services commented on HTTPCORE-481:
----------------------------------------------------------

Commit f1cf502e89d5845b60e1d8573e9e8fe07e306644 in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=f1cf502 ]

HTTPCORE-481: async request executor to treat non-error (status >= 200 and 
status < 400) out of sequence responses as valid


> Early response suspends output even when response status is not error
> ---------------------------------------------------------------------
>
>                 Key: HTTPCORE-481
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-481
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.4.5
>            Reporter: Tuomas Kiviaho
>            Assignee: Oleg Kalnichevski
>             Fix For: 4.4.7
>
>
> I have a {{text/event-stream}} response where status code 200 is sent 
> immediately back even when there is still request body streaming in process. 
> This works well with Jetty client but for some reason I could only receive 
> the first full buffer at server side when switching over to HttpAsyncClient. 
> The only visible notion that something went wrong was Jetty doing an idle 
> timeout cleanup. Luckily there is a notion of connection state which got 
> invalidated when response was received but only when request body streaming 
> was still in progress.
> I found out via this link 
> https://stackoverflow.com/questions/14250991/is-it-acceptable-for-a-server-to-send-a-http-response-before-the-entire-request
>  that probably the reason behind the behavior is to prevent flooding the 
> server in case of an error.
> {quote}
> 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.
> {quote}
> Below is a patch that currently functions as a work-a-round for me. I'd still 
> prefer the current behavior in case of unauthorized authentication etc. 
> because the request body can be quite large.
> {code:title=org/apache/http/nio/protocol/HttpAsyncRequestExecutor.java:295}
>          } else if (state.getRequestState() == MessageState.BODY_STREAM) {
>              // Early response
> +            if (statusCode >= 400) {
>                 conn.resetOutput();
>                 conn.suspendOutput();
>                 state.setRequestState(MessageState.COMPLETED);
>                 state.invalidate();
> +            }
>          }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Reply via email to