hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-481) Early response suspends output even when response status is not error
Date Fri, 11 Aug 2017 15:32:02 GMT

    [ 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

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

View raw message