[jira] [Resolved] (HTTPCLIENT-2200) Protocol interceptors are executed before the connection route has been fully established

[Oleg Kalnichevski (Jira)]

 [ 
https://issues.apache.org/jira/browse/HTTPCLIENT-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-2200.
---
Fix Version/s: 5.2-alpha2
   Resolution: Fixed

> Protocol interceptors are executed before the connection route has been fully 
> established
> -
>
> Key: HTTPCLIENT-2200
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2200
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.2-alpha1
>Reporter: Andrei Vasilev
>Priority: Major
> Fix For: 5.2-alpha2
>
>
> Currently, a user is able to add HttpRequestInterceptor when building a new 
> client using HttpAsyncClientBuilder. However, when executing a request, these 
> interceptors are called at point when the final application protocol has not 
> been established yet. The protocol returned by httpcontext is always 
> http/1.1, the protocol of the initial CONNECT request. Since the interceptors 
> do not have access to the final protocol, then the user must commit to an 
> application protocol pre-emptively when constructing their request in terms 
> of header capitalization, including the Host/Connection header or not, how 
> cookies are appended, etc. This is clearly problematic since it cannot be 
> known pre-emptively what protocol the server on the other end will end up 
> choosing when a connection is established. 
> On line 925 of HttpAsyncClientBuilder, I can see that a DefaultHttpProcessor 
> is provided to the IOEventHandlerFactory, which contains 
> HttpRequestInterceptors that DO have access to the final application protocol 
> information, because they are called at a later point in time when this 
> information has been fully established. I see that if the protocol was 
> assumed by the user to be H2, but the final connection ends up using 1.1, 
> then a Host and Connection header are added to the request if they are 
> missing. However, the opposite is not provided. That is, if the protocol is 
> assumed to be 1.1 and the Host / Connection headers are included by the user, 
> but the connection upgrades to H2, it results in an illegal request due to 
> invalid headers.
> To solve this issue, it would be nice if a user was able to add additional 
> interceptors to the DefaultHttpProcessor on line 925, so that they too are 
> able to have access to protocol information and potentially augment their 
> request where needed.
> https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/async/HttpAsyncClientBuilder.java



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (HTTPCLIENT-2200) Protocol interceptors are executed before the connection route has been fully established

[ASF subversion and git services (Jira)]

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

ASF subversion and git services commented on HTTPCLIENT-2200:
-

Commit f00ce5da9ef8b0de42717e62ccdbf30765e25af3 in httpcomponents-client's 
branch refs/heads/master from Oleg Kalnichevski
[ https://gitbox.apache.org/repos/asf?p=httpcomponents-client.git;h=f00ce5d ]

HTTPCLIENT-2200: Protocol interceptors are executed before the connection route 
has been fully established


> Protocol interceptors are executed before the connection route has been fully 
> established
> -
>
> Key: HTTPCLIENT-2200
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2200
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.2-alpha1
>Reporter: Andrei Vasilev
>Priority: Major
>
> Currently, a user is able to add HttpRequestInterceptor when building a new 
> client using HttpAsyncClientBuilder. However, when executing a request, these 
> interceptors are called at point when the final application protocol has not 
> been established yet. The protocol returned by httpcontext is always 
> http/1.1, the protocol of the initial CONNECT request. Since the interceptors 
> do not have access to the final protocol, then the user must commit to an 
> application protocol pre-emptively when constructing their request in terms 
> of header capitalization, including the Host/Connection header or not, how 
> cookies are appended, etc. This is clearly problematic since it cannot be 
> known pre-emptively what protocol the server on the other end will end up 
> choosing when a connection is established. 
> On line 925 of HttpAsyncClientBuilder, I can see that a DefaultHttpProcessor 
> is provided to the IOEventHandlerFactory, which contains 
> HttpRequestInterceptors that DO have access to the final application protocol 
> information, because they are called at a later point in time when this 
> information has been fully established. I see that if the protocol was 
> assumed by the user to be H2, but the final connection ends up using 1.1, 
> then a Host and Connection header are added to the request if they are 
> missing. However, the opposite is not provided. That is, if the protocol is 
> assumed to be 1.1 and the Host / Connection headers are included by the user, 
> but the connection upgrades to H2, it results in an illegal request due to 
> invalid headers.
> To solve this issue, it would be nice if a user was able to add additional 
> interceptors to the DefaultHttpProcessor on line 925, so that they too are 
> able to have access to protocol information and potentially augment their 
> request where needed.
> https://github.com/apache/httpcomponents-client/blob/master/httpclient5/src/main/java/org/apache/hc/client5/http/impl/async/HttpAsyncClientBuilder.java



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Updated] (HTTPCORE-702) Improve connection limit guarantees

[Oleg Kalnichevski (Jira)]

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski updated HTTPCORE-702:
---
Fix Version/s: (was: 5.2-beta1)

> Improve connection limit guarantees
> ---
>
> Key: HTTPCORE-702
> URL: https://issues.apache.org/jira/browse/HTTPCORE-702
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.14
> Environment: Ubuntu 18.04.6 LTS
> OpenJDK version 11.0.11
>Reporter: Nikola Bekcic
>Priority: Minor
>  Labels: volunteers-wanted
>
> h3. Background
> To manage the life cycle and re-use HTTP connections we are using 
> *PoolingHttpClientConnectionManager* with the maximum limit of connections 
> defined on a per route basis as well as in total.
> Using PoolingHttpClientConnectionManager and built-in Java management 
> utilities, I want to provide our users with the option to dynamically re-size 
> the connection pool (up and/or down) at runtime without redeploying or 
> restarting the application with a new configuration.
> h3. Issue description
> During testing, we found that decreasing the maximum limit of connection per 
> route does not have (an immediate) effect on the pool size i.e maximum number 
> of connections per route is staying the same (potentially for a very long 
> time).
> E.g. let's use only two routes where the default maximum connections per 
> route are 10 and the maximum total is 20. At some point, the maximum number 
> of connections per route will be riched and the number of allocated 
> connections (available + leased) will be 10. Now, let's say that we need to 
> decrease the maximum number of connections per route to 5, for any reason. 
> Doing that by calling either 
> _PoolingHttpClientConnectionManager#setDefaultMaxPerRoute(int)_ or 
> _PoolingHttpClientConnectionManager#setMaxPerRoute(HttpRoute, int)_ will not 
> change the pool size and the maximum number of connections per route will 
> stay the same (potentially for a very long time).
> This is the sample of the pool stats printed after changing +maxPerRoute+ to 
> 5:
> {noformat}
> {somehost1:8983={"available":4,"leased":6,"max":5,"pending":0}, 
> somehost2:8080={"available":1,"leased":9,"max":5,"pending":2}}
> {somehost1:8983={"available":4,"leased":6,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":2}}
> {somehost1:8983={"available":5,"leased":5,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":4}}
> {somehost1:8983={"available":5,"leased":5,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":4}}
> {somehost1:8983={"available":7,"leased":3,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":5}}
> {somehost1:8983={"available":9,"leased":1,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":5}}
> {somehost1:8983={"available":9,"leased":1,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
> {somehost1:8983={"available":8,"leased":2,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
> {somehost1:8983={"available":9,"leased":1,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
> {somehost1:8983={"available":8,"leased":2,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":7}}
> {somehost1:8983={"available":8,"leased":2,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
> {somehost1:8983={"available":8,"leased":2,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
> {somehost1:8983={"available":9,"leased":1,"max":5,"pending":0}, 
> somehost2:8080={"available":0,"leased":10,"max":5,"pending":6}}
> {somehost1:8983={"available":9,"leased":1,"max":5,"pending":0}, 
> somehost2:8080={"available":1,"leased":9,"max":5,"pending":6}}} {noformat}
> As you can see, not only that the number of allocated connections per route 
> is still 10, but also very often the number of leased connection is higher 
> than 5. In my opinion, this is not what is expected and not really in favor 
> of the principle of least surprise.
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (HTTPCLIENT-2163) [OSGi Metatype] Mark password property as password type

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2163:
---

[~sagarmiglani] I will try to get around to it in April but do not take it as a 
promise.

Oleg

> [OSGi Metatype] Mark password property as password type
> ---
>
> Key: HTTPCLIENT-2163
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2163
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async)
>Affects Versions: 4.5.13
>Reporter: Carsten Ziegeler
>Priority: Major
> Fix For: 4.5.14
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The OSGi configuration for the http client can be configured with a proxy 
> user and password. Right now the password is marked as String. This should 
> actually be marked as type Password so tooling processing the configuration 
> knows that this property contains a secret and can handle it as such



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[ANNOUNCEMENT] HttpComponents Core 5.2-beta1 released

[Oleg Kalnichevski]

The Apache HttpComponents project is pleased to announce 5.2-beta1
release of HttpComponents Core.

This is the first BETA release in the 5.2 release series that marks the
completion of major API changes and starts the transition toward a GA
phase.

This release also includes all fixes from the 5.1 (stable) branch.

Please note that 5.2 upgrades minimal JRE level to version 8 (8u251 is
required).

Notable changes and features included in the 5.2 series:

* Upgrade to Java 8.
* Improved support for TLS upgrade and HTTP protocol upgrade (async).
* Improved HTTP protocol negotiation.
* Improved customization of HTTP listeners (async).
* Improved parsing and formatting of URI components.
* Use of Java 1.8 date / time APIs

Download - 

Release notes - <
http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES-5.2.x.txt
HttpComponents site - 

About HttpComponents Core

HttpCore is a set of HTTP/1.1 and HTTP/2 transport components that can
be used to build custom client and server side HTTP services with a
minimal footprint


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

[jira] [Comment Edited] (HTTPCLIENT-2185) Add support for IDNA 2008 (RFC 5891)

[asuka amamiya (Jira)]

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

asuka amamiya edited comment on HTTPCLIENT-2185 at 3/17/22, 10:25 AM:
--

Hi, i want support this, do you give me same url?

I need test that


was (Author: JIRAUSER286678):
Hi, i want support this, do you give me same url.

I need test that

> Add support for IDNA 2008 (RFC 5891)
> 
>
> Key: HTTPCLIENT-2185
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2185
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Android Port, HttpClient (async), HttpClient (classic), 
> HttpClient (Windows)
>Affects Versions: 5.0
> Environment: Android SDK 30
>Reporter: Julien Bernard
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> The tests have been conducted with Kotlin on Android SDK 30 with Apache 
> HttpClient Android extensions which ships with HttpClient version 5.0.1 but 
> any HttpClient component on any platform may be impacted.
> Before making an HTTP query the client should convert the URL domain to 
> A-label as described in [RFC 
> 5891|https://datatracker.ietf.org/doc/html/rfc5891].
> Here is an example with the trustworthy ICU4J library:
>  
> {code:java}
> int flags = IDNA.CHECK_BIDI
>| IDNA.CHECK_CONTEXTJ
>| IDNA.CHECK_CONTEXTO
>|  IDNA.NONTRANSITIONAL_TO_ASCII
>| IDNA.USE_STD3_RULES;
> IDNA idna = IDNA.getUTS46Instance(flags);
> IDNA.Info info = new IDNA.Info();
> String domainAscii = idna.nameToASCII(domain, new StringBuilder(), info);
> // check error with info.hasErrors() {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (HTTPCLIENT-2185) Add support for IDNA 2008 (RFC 5891)

[asuka amamiya (Jira)]

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

asuka amamiya commented on HTTPCLIENT-2185:
---

Hi, i want support this, do you give me same url.

I need test that

> Add support for IDNA 2008 (RFC 5891)
> 
>
> Key: HTTPCLIENT-2185
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2185
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Android Port, HttpClient (async), HttpClient (classic), 
> HttpClient (Windows)
>Affects Versions: 5.0
> Environment: Android SDK 30
>Reporter: Julien Bernard
>Priority: Minor
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> The tests have been conducted with Kotlin on Android SDK 30 with Apache 
> HttpClient Android extensions which ships with HttpClient version 5.0.1 but 
> any HttpClient component on any platform may be impacted.
> Before making an HTTP query the client should convert the URL domain to 
> A-label as described in [RFC 
> 5891|https://datatracker.ietf.org/doc/html/rfc5891].
> Here is an example with the trustworthy ICU4J library:
>  
> {code:java}
> int flags = IDNA.CHECK_BIDI
>| IDNA.CHECK_CONTEXTJ
>| IDNA.CHECK_CONTEXTO
>|  IDNA.NONTRANSITIONAL_TO_ASCII
>| IDNA.USE_STD3_RULES;
> IDNA idna = IDNA.getUTS46Instance(flags);
> IDNA.Info info = new IDNA.Info();
> String domainAscii = idna.nameToASCII(domain, new StringBuilder(), info);
> // check error with info.hasErrors() {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[jira] [Commented] (HTTPCLIENT-2210) HttpClient Log4j examples refer to non-existing `Console` appender

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2210:
---

[~enterit] Would you mind contributing these changes as a PR at GitHub [1] ?

Oleg

[1]https://github.com/apache/httpcomponents-website

> HttpClient Log4j examples refer to non-existing `Console` appender
> --
>
> Key: HTTPCLIENT-2210
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2210
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Sergey Bondarenko
>Priority: Minor
>
> Log4j configuration examples in 
> [https://hc.apache.org/httpcomponents-client-5.1.x/logging.html] refer to two 
> appenders - one named 'STDOUT', and one named 'Console'.
> However, the config only defines one appender named 'STDOUT'.
> Incorrect reference produces an error:
> {code:java}
> ERROR Unable to locate appender "Console" for logger config 
> "org.apache.hc.client5.http" {code}
>  
> Config example copied from the doc:
>  
> {code:java}
> 
>   
> 
>   
> 
>   
>   
> 
>   
> 
> 
>   
> 
> 
>   
> 
>   
>  {code}
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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

[VOTE][RESULT] Release HttpComponents HttpCore 5.2-beta1 based on RC1

[Oleg Kalnichevski]

The vote to release HttpComponents HttpCore 5.2-beta1 based on RC1 has
passed with the following results

+1 (3 binding votes in total)
Michael Osipov  *
Gary Gregory  *
Arturo Bernal 
Oleg Kalnichevski  *

no other votes

* binding votes

Original voting thread:
https://lists.apache.org/thread/8vv3d7w41zjmcpn4fnh5vy2mtwcq265v


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