You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Michael Osipov (Jira)" <ji...@apache.org> on 2020/07/21 19:57:00 UTC
[jira] [Comment Edited] (HTTPCORE-639) Consider a configurable
ResponseOutOfOrder strategy for DefaultBHttpClientConnection
[ https://issues.apache.org/jira/browse/HTTPCORE-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162312#comment-17162312 ]
Michael Osipov edited comment on HTTPCORE-639 at 7/21/20, 7:56 PM:
-------------------------------------------------------------------
Hi Carter, thanks for another quality ticket. I assume that you have read the thread which introduced this change.
A question before we start, why are your servers suboptimal by consuming the entire body, but still rejecting based on headers?
Why does your interface not contain two methods? For the chunk size and the timeout? How would an implementation for you look like when request and socket are necessary? Aren't two config options enough?
was (Author: michael-o):
Hi Carter, thanks for another quality ticket. I assume that you have read the thread which introduced this changed.
A question before we start, why are your servers suboptimal by consuming the entire body, but still rejecting based on headers?
Why does your interface not contain two methods? For the chunk size and the timeout? How would an implementation for you look like when request and socket are necessary? Aren't two config options enough?
> Consider a configurable ResponseOutOfOrder strategy for DefaultBHttpClientConnection
> ------------------------------------------------------------------------------------
>
> Key: HTTPCORE-639
> URL: https://issues.apache.org/jira/browse/HTTPCORE-639
> Project: HttpComponents HttpCore
> Issue Type: New Feature
> Components: HttpCore
> Reporter: Carter Kozak
> Priority: Major
>
> In a known environment where the server fully reads full request bodies before sending a response, I would like to disable the expensive checkForEarlyResponse checks implemented by DefaultBHttpClientConnection.sendRequestEntity.
> Using TLS the check blocks for 1ms every 8kb, which limits the upload rate to at most eight megabytes per second, relatively low in a data-center environment.
> Proposed interface:
> {code:java}
> public interface ResponseOutOfOrderStrategy {
> /**
> * Returns the interval in bytes describing how often the socket is checked for an out-of-order response.
> * The default implementation uses 8kb. A value of zero results in checks being disabled, this may result
> * in requests blocking until the socket timeout is reached while a server sends an out-of-order response.
> */
> int determineResponseCheckIntervalBytes(ClassicHttpRequest request, Socket socket);
> }
> {code}
> I'd be happy to implement and contribute such a feature if you agree that it's reasonable.
> I appreciate any input and feedback you can provide!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org