[jira] [Commented] (HTTPCORE-718) Getting org.apache.http.ConnectionClosedException after httpcore-nio version upgrade

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-718:


[~sajiniekavindya] Your chunking code is _completely_ wrong!!! There are 
_multiple_ HTTP spec violations in your server code. This is how it is supposed 
to be
{code:java}
int count;
byte[] buffer = new byte[10453];
while ((count = payload.read(buffer)) > 0) {
System.out.println("server chunk size: " + count);
out.print(Integer.toHexString(count)+"\r\n");
out.write(buffer, 0, count);
out.print("\r\n");
out.flush();
}

System.out.println("server chunk size: " + 0);
out.print("0\r\n");
out.print("\r\n");
out.flush();
out.close(); // Flush and close the output stream
payload.close(); // Close the input stream
client.close(); // Close the socket itself
{code}
With chunk coding corrected your test app works as expected
{noformat}
Backend server started!
server chunk size: 1410
HTTP/1.1 200 Ok [Content-Type: application/json, Connection: keep-alive, 
Transfer-Encoding: chunked] [Content-Type: application/json,Chunked: true]
server chunk size: 0
Shutting down I/O reactor
https://localhost:7005->HTTP/1.1 200 Ok
Input : [
Input :   {
Input : "_id": "61b83809ce532e8c96ae5d59",
Input : "index": 0,
Input : "guid": "755fd8b2-cb7e-457c-84ca-bdf3041af2e1",
Input : "isActive": false,
Input : "balance": "$1,268.32",
Input : "picture": "http://placehold.it/32x32;,
Input : "age": 23,
Input : "eyeColor": "blue",
Input : "name": "Dina Mcknight",
Input : "gender": "female",
Input : "company": "DATACATOR",
Input : "email": "dinamckni...@datacator.com",
Input : "phone": "+1 (821) 543-2109",
Input : "address": "422 Benson Avenue, Fairview, Florida, 1068",
Input : "about": "Excepteur officia in velit magna do consequat qui magna 
velit. Ex ipsum sunt consectetur exercitation fugiat. Consequat ullamco aute 
exercitation veniam proident. Ex laboris sunt consectetur est consectetur dolor 
ipsum dolor nostrud. Aute elit culpa Lorem non ullamco in elit. Lorem mollit ea 
aliquip reprehenderit nulla commodo non nisi ex aliquip enim anim esse.\r\n",
Input : "registered": "2015-01-30T01:31:24 -06:-30",
Input : "latitude": -69.668784,
Input : "longitude": -159.012416,
Input : "tags": [
Input :   "aliquip",
Input :   "voluptate",
Input :   "laborum",
Input :   "non",
Input :   "et",
Input :   "ut",
Input :   "irure"
Input : ],
Input : "friends": [
Input :   {
Input : "id": 0,
Input : "name": "Malinda Curry"
Input :   },
Input :   {
Input : "id": 1,
Input : "name": "Brittany Buck"
Input :   },
Input :   {
Input : "id": 2,
Input : "name": "Corrine Solomon"
Input :   }
Input : ],
Input : "greeting": "Hello, Dina Mcknight! You have 9 unread messages.",
Input : "favoriteFruit": "apple"
Input :   }
Input : ]
Done
Shutdown
Shutting down the backend server
{noformat}
Oleg

> Getting org.apache.http.ConnectionClosedException after httpcore-nio version 
> upgrade
> 
>
> Key: HTTPCORE-718
> URL: https://issues.apache.org/jira/browse/HTTPCORE-718
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.15
> Environment: Java version: 11.0.15.1
> OS: macOS Monterey (Version 12.12.1) 
>Reporter: Sajinie Kavindya
>Priority: Major
> Attachments: HttpNIOTestClient-1.zip
>
>
> We recently migrated to httpcore-nio 4.4.15 and we have been encountering 
> some issues when connecting to an HTTPS Backend that sends chunked responses. 
> The backend behaves in such a manner that when it sends the response, it 
> immediately closes the connection after completion. 
> We have

[jira] [Resolved] (HTTPCORE-718) Getting org.apache.http.ConnectionClosedException after httpcore-nio version upgrade

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-718.

Resolution: Invalid

> Getting org.apache.http.ConnectionClosedException after httpcore-nio version 
> upgrade
> 
>
> Key: HTTPCORE-718
> URL: https://issues.apache.org/jira/browse/HTTPCORE-718
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.15
> Environment: Java version: 11.0.15.1
> OS: macOS Monterey (Version 12.12.1) 
>Reporter: Sajinie Kavindya
>Priority: Major
> Attachments: HttpNIOTestClient-1.zip
>
>
> We recently migrated to httpcore-nio 4.4.15 and we have been encountering 
> some issues when connecting to an HTTPS Backend that sends chunked responses. 
> The backend behaves in such a manner that when it sends the response, it 
> immediately closes the connection after completion. 
> We have attached a reproducer to this ticket and the behavior is as below.
> When httpcore-nio 4.4.15 is used, the client gets the error:
> {code:java}
> org.apache.http.ConnectionClosedException: Connection closed 
> unexpectedly{code}
> But, when httpcore-nio 4.4.5 is used, the client receives the complete 
> response, which was sent from the backend.
> We further checked on the following versions and the observations are as 
> below. 
>  * httpcore-nio 4.4.10 - receives the complete response
>  * httpcore-nio 4.4.11 - receives org.apache.http.ConnectionClosedException
> In order to replicate the issue, we did a few changes to the 
> consumeContent(final ContentDecoder decoder) method inside the 
> SimpleInputBuffer class. You may find the changes in the attached source code.
> In order to test the behavior, please run the Main class: 
> “{*}TestChunkedBackend{*}”.
> Tested environment:
>  * Java version: 11.0.15.1
>  * OS: macOS Monterey (Version 12.12.1) 
> A similar issue can be found here 
> [https://issues.apache.org/jira/browse/HTTPCORE-706|http://example.com]
> Thanks & Regards,
> Sajinie
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2227) HttpClient API docs are not reachable

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2227:
---

Thank you [~michael-o]  for tracking down the cause of the problem.

Oleg

> HttpClient API docs are not reachable
> -
>
> Key: HTTPCLIENT-2227
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2227
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Site
>Reporter: Sam Brannen
>Assignee: Michael Osipov
>Priority: Major
>
> https://hc.apache.org/httpcomponents-client-5.1.x/current/httpclient5/apidocs/
>  results in 403 "Forbidden: You don't have permission to access this 
> resource.".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2227) HttpClient API docs are not reachable

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2227:
---

>  I cannot find the tag in Git:

[~michael-o] I can see the tags here [1]. They exist in the remote repository. 
Please do make sure you pull them with Git

> the issue wasn't Maven Site related at all. Symlinks weren't followed.

I m not sure I understand. What do you mean by "weren't followed"?

Oleg

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

> HttpClient API docs are not reachable
> -
>
> Key: HTTPCLIENT-2227
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2227
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Site
>Reporter: Sam Brannen
>Assignee: Michael Osipov
>Priority: Major
>
> https://hc.apache.org/httpcomponents-client-5.1.x/current/httpclient5/apidocs/
>  results in 403 "Forbidden: You don't have permission to access this 
> resource.".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2228) Apache Http Client library does not sending Authorization header/Sending different Host Header when routing requests (Whatever is intended) to our back-end service

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2228:
---

[~Prakash D] We are not going to remote debug _your_ application code. If you 
expect us to act on this issue please provide a standalone test application or 
a unit test that can be executed _outside_ of your application environment 
exhibiting the behavior you consider incorrect.

Oleg

> Apache Http Client library does not sending Authorization header/Sending 
> different Host Header when routing requests (Whatever is intended) to our 
> back-end service. 
> -
>
> Key: HTTPCLIENT-2228
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2228
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Prakash D
>Priority: Critical
> Attachments: image-2022-07-14-16-42-56-494.png, 
> image-2022-07-14-16-43-14-435.png, image-2022-07-14-16-44-10-587.png, 
> image-2022-07-18-22-55-47-009.png
>
>
> Apache Http Client library does not send Authorization header when routing 
> requests to our back-end service. This issue we are seeing intermittently. 
> Customers are seeing this issue very frequently in their environments.
> Authorization Header is coming:
> !image-2022-07-14-16-43-14-435.png!
> Authorization Header is missing:
> !image-2022-07-14-16-44-10-587.png!
>  
> We have upgraded our http library from 4.2.5 to 4.5.13. Still we are seeing 
> the same issue.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2230) IOReactorShutdownException: I/O reactor has been shut down, using apache httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2230:
---

I am not sure what you expect us to do here. There can be all sorts of reasons 
for an I/O reactor to be in the shutdown state such as termination by the user 
or due to an internal error. However in the latter case one should get a log 
entry at ERROR priority.

I will have to close this issue as invalid without a reliable reproducer.

Oleg

> IOReactorShutdownException: I/O reactor has been shut down, using apache 
> httpclient5
> 
>
> Key: HTTPCLIENT-2230
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2230
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.0
>Reporter: Assaf Zvigoren
>Priority: Major
> Fix For: 5.0
>
>
> we recently upgraded our httpclient version from 4.x to 5.0.3. 
> The main reason for the upgrade is to get rid of the 
> {code:java}
> java.lang.IllegalStateException: Request cannot be executed; I/O reactor 
> status: STOPPED{code}
>  exception that accures on version 4.x.
> After the upgrade, for some unknown reason we are experiencing this error 
> now: 
> {code:java}
> 22:35:04,160 (pool-9-thread-1] ERROR http.async.HttpAsyncSender - Unable to 
> send request, cause-I/O reactor has been shut down
> org.apache.ha.cores.reactor. IOReactorShutdownException: I/O reactor has been 
> shut down at 
> org.apache.ho.cores.reactor.AbstractIOReactorBase.connect(AbstractIOReactorBase.java:50)-thespoores-5.0.2.341/15.0.21
> at 
> org.apache.ha.clients.http.impl.nio.Maltihome105essionRequesterfi.executellext
>  (Multihome10Sessionequester.java:105) -[httpolients-5.0.3.3art/25.0.31 37021 
> at org.apache.he.clients.http.impl.nic.MultihomeI0SessionRequester$1.run 
> (Multihome105essionRequester.java:153) -(httpclients-5.0.3.jar/15.0.3)
> at org.apache.hc.clients.http.impl.nio.Multihome10SessionRequester.connect 
> (Multihome 10dessionequester-java:157)-[httpclient5-5.0.3.Jaz1/15.0.31 at 
> org.apache.he.clients.http.impl.nio.DefaultAsyncClientConnectionOperator.connect
>  (DefaultAsyncClientConnectionOperator.java:30) 
> -[httpclients-5.0.3.jar!/15.0.3)
> at 
> org.apache.ho.clients.http.impl.nio.PoolingAsyncClientConnectionManager.connect
>  (FoolingAsyncClientConnectionManager.java:369) 
> -[httpclients-5.0.3.jar!/15.0.3)
> at 
> org.apache.he.clients.http.impl.wayng.InternalfetpAsyncExecRuntime.connectEndpoint
>  (InternalttpAsynckxeckuntime.JAVA:210)-[httpclients-5.0.3-3art/15.0.31 at 
> org.apache.ho.clients.http.impl.async.AsyncConnectExec.proceedTolfextop 
> (AsyncConnectExec.java:195) -httpeltent5-5.0.3.jar/5.0.31
> at org.apache.ba.clients.http.impl.async.AsyncConnectExec.access2000 
> (AsyncConnectExec.java:79)-[httpclients-5.0.3.jar/15.0.3) at 
> org.apache.ho.clients.http.impl-axyng.AsyncConnectExec.completed 
> (AsyncConnectExec.java:146) -Thespelients-5.0.3.jar!/15.0.3)
> at org.apache.bo.clients.http-impl-async.AsyncConnectExecli.completed 
> (AsyncConnectExec.java:135) -(httpelients-5.0.3.jar!/15.0.3)
> at 
> org.apache.hc.clients.http.impl.axyng.InternalttpAsyncExecRuntimesi.completed 
> (InternalNetpayncExecRuntime.java:114) -[httpclients-3.0.3.3art/15.0.3) at 
> org.apache.bo.clients.http.impl.async.InternalfetpAryncExecRuntime1.completed 
> [InternalttpAsyncExecRuntime.java:105) -(httpaliest5-5.0.3.jar!/15.0.31
> at org.apache.bc.cores.concurrent.Basicfuture.completed 
> (Basicfuture.java:123) (httpoores-5.0.2.jar!/15.0.21 at 
> org.apache.hc.cores.concurrent.ComplexFuture.completed (Complexfuture.179) 
> (httpceres-5.0.2.jart/:5.0.21
> at peg.apache.he.clients.http.impl.nio.PoolingAsyncClientConnectionManager$1. 
> leaseCompleted (PoolingAsyncClientConnectionManager.java:240) 
> -[httpclients-5.0.3.3art/15.0.31
> at 
> org.apache.ho.clients.http.impl.nio.PoolingAsyncClientConnectionManager$1.completed/FoolingAayneClientConnectionManager.JATA1275)-[httpclients-3.0.3.3az1/15.0.31
>  at 
> org.apache.ho.clients.http.impl.nio.PoolingAsyncClientConnectionManager$1.completed(PoolingAsyncClientConnectionManager.java:224)
>  -[httpclients-8.0.3.jar!/15.0.31
> at org.apache.bs.cores.concurrent.Basicfuture.completed(BasicFuture.java:123) 
> -[httpeores-5.0.2.3art/15.0.23
> at org.apache.hc.cores.pool.strictConnPool.fireCallbacks 
> (StrictConnPool.java:383) -(httpcore5-5.0.2.jar!/15.0.23 at 
> org.apache.hc-cores.pool.strictcoonPool.Inase (Stric

[jira] [Resolved] (HTTPCLIENT-2228) Apache Http Client library does not sending Authorization header/Sending different Host Header when routing requests (Whatever is intended) to our back-end service.

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2228.
---
Resolution: Invalid

I have zero tolerance policy toward bad issue reports raised with critical 
priority. There is _absolutely_ no evidence of _any_ incorrect behavior of the 
part of HttpClient let alone anything that requires our immediate reaction.

Please *do not* reopen the issue.

Oleg

> Apache Http Client library does not sending Authorization header/Sending 
> different Host Header when routing requests (Whatever is intended) to our 
> back-end service. 
> -
>
> Key: HTTPCLIENT-2228
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2228
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Prakash D
>Priority: Critical
> Attachments: image-2022-07-14-16-42-56-494.png, 
> image-2022-07-14-16-43-14-435.png, image-2022-07-14-16-44-10-587.png
>
>
> Apache Http Client library does not send Authorization header when routing 
> requests to our back-end service. This issue we are seeing intermittently. 
> Customers are seeing this issue very frequently in their environments.
> Authorization Header is coming:
> !image-2022-07-14-16-43-14-435.png!
> Authorization Header is missing:
> !image-2022-07-14-16-44-10-587.png!
>  
> We have upgraded our http library from 4.2.5 to 4.5.13. Still we are seeing 
> the same issue.
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2229) Http cache key is not unique across http methods.

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2229:
---

Apparently this issue is a duplicate of HTTPCLIENT-1920

Oleg

> Http cache key is not unique across http methods.
> -
>
> Key: HTTPCLIENT-2229
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2229
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 5.0, 5.1
>Reporter: Akash
>Priority: Major
>
> We use HttpClient5 with 
> [MemcachedHttpCacheStorage|https://hc.apache.org/httpcomponents-client-5.1.x/current/httpclient5-cache/apidocs/]
>  configured. It seems like we get cache hit for a get request, while the 
> cached response is for a http HEAD request. Hence the cached response doesn't 
> not have response body.
> Ask here is to ensure that cache key to also include the http method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Resolved] (HTTPCLIENT-2229) Http cache key is not unique across http methods.

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2229.
---
Resolution: Duplicate

> Http cache key is not unique across http methods.
> -
>
> Key: HTTPCLIENT-2229
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2229
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 5.0, 5.1
>Reporter: Akash
>Priority: Major
>
> We use HttpClient5 with 
> [MemcachedHttpCacheStorage|https://hc.apache.org/httpcomponents-client-5.1.x/current/httpclient5-cache/apidocs/]
>  configured. It seems like we get cache hit for a get request, while the 
> cached response is for a http HEAD request. Hence the cached response doesn't 
> not have response body.
> Ask here is to ensure that cache key to also include the http method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2229) Http cache key is not unique across http methods.

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2229:
---

> Ask here is to ensure that cache key to also include the http method.

[~akasham1992] No, it does not. I am not sure why and the original developer of 
the caching module is no longer with the project. I suppose the correct 
behavior should be to cache response messages of GET requests only but return 
the response head to HEAD requests for the same request URI.

Oleg

> Http cache key is not unique across http methods.
> -
>
> Key: HTTPCLIENT-2229
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2229
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 5.0, 5.1
>Reporter: Akash
>Priority: Major
>
> We use HttpClient5 with 
> [MemcachedHttpCacheStorage|https://hc.apache.org/httpcomponents-client-5.1.x/current/httpclient5-cache/apidocs/]
>  configured. It seems like we get cache hit for a get request, while the 
> cached response is for a http HEAD request. Hence the cached response doesn't 
> not have response body.
> Ask here is to ensure that cache key to also include the http method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[jira] [Commented] (HTTPCLIENT-2227) HttpClient API docs are not reachable

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2227:
---

I have no idea why Maven Site documentation links stopped working. They used 
to. Anyone with fondness for Maven Site plugin and preferably with some 
experience as well is welcome to investigate.

I once again rather start looking for ways to replace Maven Site with something 
else.

Oleg

> HttpClient API docs are not reachable
> -
>
> Key: HTTPCLIENT-2227
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2227
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Site
>Reporter: Sam Brannen
>Priority: Major
>
> https://hc.apache.org/httpcomponents-client-5.1.x/current/httpclient5/apidocs/
>  results in 403 "Forbidden: You don't have permission to access this 
> resource.".



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

[ANNOUNCEMENT] HttpComponents Core 5.1.4 GA released

[Oleg Kalnichevski]

The Apache HttpComponents project is pleased to announce 5.1.4 GA
release of HttpComponents Core. 

This is a maintenance release that corrects a number of defects
discovered since release 5.1.3, mostly in H2 protocol handling.

Please note that HttpCore 5.1 is likely to be the last release series
compatible with Java 1.7. As of release 5.2 HttpCore will require Java
1.8. 

Download - 
Release notes -


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] [Resolved] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-716.

Fix Version/s: 4.4.16
   Resolution: Fixed

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Fix For: 4.4.16
>
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.jar, 
> HttpNIOTestServer.zip, HttpNIOTestServer2.zip, testclient 2.zip, 
> testclient.jar
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
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.1.4 based on RC1

[Oleg Kalnichevski]

The vote to release HttpComponents HttpCore 5.1.4 based on RC1 has
passed with the following results

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

no other votes

* binding votes

Original voting thread:
https://lists.apache.org/thread/mfrjcvxkd86xx784z9l3p1r0qszz3mhl

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

Integration test execution time; Re: [VOTE] Release HttpCore 5.1.4 based on RC1

[Oleg Kalnichevski]

On Sun, 2022-07-03 at 17:37 -0400, Gary Gregory wrote:
> 

> 
> The httpcore5-testing module is very slow on my machine compared to
> the other modules. Anyone else? The whole build takes 27 minutes!
> It's
> never been this long.
> 
> Tested using:
> 
> openjdk version "1.8.0_322"
> OpenJDK Runtime Environment (build 1.8.0_322-bre_2022_02_28_15_01-
> b00)
> OpenJDK 64-Bit Server VM (build 25.322-b00, mixed mode)
> 

Hi Gary

I observed a similar problem, albeit a long time ago. This usually
happens if TLS context initialization and / or shutdown takes massively
longer than usual. Given the total number of TLS sessions it can all
add up to something like 15 minutes or more. 

I have no Mac at my disposal, however, and I cannot verify if this is
the case with your particular setup. Please try to find out where the
time is being spent in tests.

Oleg  



> Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
> Maven home: /usr/local/Cellar/maven/3.8.6/libexec
> Java version: 1.8.0_322, vendor: Homebrew, runtime:
> /usr/local/Cellar/openjdk@8/1.8.0+322/libexec/openjdk.jdk/Contents/Ho
> me/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "mac os x", version: "12.4", arch: "x86_64", family: "mac"
> 
> Darwin *** 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22
> PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
> 
> 
> On Sat, Jul 2, 2022 at 4:46 AM Oleg Kalnichevski 
> wrote:
> > 
> > Please vote on releasing these packages as HttpCore 5.1.4.
> > The vote is open for the at least 72 hours, and only votes from
> > HttpComponents PMC members are binding. The vote passes if at least
> > three binding +1 votes are cast and there are more +1 than -1
> > votes.
> > 
> > Release notes:
> > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.1.4-RC1/RELEASE_NOTES-5.1.x.txt
> > 
> > Maven artefacts:
> > https://repository.apache.org/content/repositories/orgapachehttpcomponents-1149/org/apache/httpcomponents/core5/
> > 
> > Git Tag: 5.1.4-RC1
> >  https://github.com/apache/httpcomponents-core/tree/5.1.4-RC1
> > 
> > Packages:
> > https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.1.4-RC1
> >  revision 55418
> > 
> > Hashes:
> > 6c842ed09007b0e54c50acb02c0b76de0845590f42e50721e1b6825a2e6838384a8
> > 3a933
> > 44599ad5cc1bb0f97e6d2b992e1ea303cbed582fc0f6642c27ba4758
> > httpcomponents-core-5.1.4-bin.zip httpcomponents-core-5.1.4-bin.zip
> > 0cdc34fac5f48db0da136888d1b62950fb61e8d802d2d13b0f99b351b20552cc9d9
> > 042bc
> > 3549682a908d50eff8ce2eb6193dea1fadd22c408acd4792e7892f73
> > httpcomponents-core-5.1.4-bin.tar.gz httpcomponents-core-5.1.4-
> > bin.tar.gz
> > 7739a82f23d892552e146aa3f3e3646cb01e74055e5196ddbb711800dd7d135e0c7
> > 4c362
> > 56fb3a4992478291cc33b7fe0d0362345166410d26fa71f393203ab0
> > httpcomponents-core-5.1.4-src.zip httpcomponents-core-5.1.4-src.zip
> > 9a94bad22f8d6757a3d5effce73e81279c45176eaa265404476878d48204365db4c
> > 04638
> > f1f732e8e3e6a03d0ad1c3cf895649cb33eb249b3e89b2846fabda6e
> > httpcomponents-core-5.1.4-src.tar.gz httpcomponents-core-5.1.4-
> > src.tar.gz
> > 
> > Keys:
> >  https://www.apache.org/dist/httpcomponents/httpcore/KEYS
> > 
> > ---
> > 
> > ---
> > Vote: HttpCore 5.1.4 release
> > [ ] +1 Release the packages as HttpCore 5.1.4.
> > [ ] -1 I am against releasing the packages (must include a reason).
> > 
> > 
> > ---
> > --
> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > For additional commands, e-mail: dev-h...@hc.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 


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

Re: [VOTE] Release HttpCore 5.1.4 based on RC1

[Oleg Kalnichevski]

[x] +1 Release the packages as HttpCore 5.1.4.

On Sat, 2022-07-02 at 10:46 +0200, Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.1.4.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and there are more +1 than -1 votes.
> 
> Release notes:
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.1.4-RC1/RELEASE_NOTES-5.1.x.txt
> 
> Maven artefacts:
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1149/org/apache/httpcomponents/core5/
> 
> Git Tag: 5.1.4-RC1
>  https://github.com/apache/httpcomponents-core/tree/5.1.4-RC1
> 
> Packages:
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.1.4-RC1
>  revision 55418
> 
> Hashes:
> 6c842ed09007b0e54c50acb02c0b76de0845590f42e50721e1b6825a2e6838384a83a
> 933
> 44599ad5cc1bb0f97e6d2b992e1ea303cbed582fc0f6642c27ba4758
> httpcomponents-core-5.1.4-bin.zip httpcomponents-core-5.1.4-bin.zip
> 0cdc34fac5f48db0da136888d1b62950fb61e8d802d2d13b0f99b351b20552cc9d904
> 2bc
> 3549682a908d50eff8ce2eb6193dea1fadd22c408acd4792e7892f73
> httpcomponents-core-5.1.4-bin.tar.gz httpcomponents-core-5.1.4-
> bin.tar.gz
> 7739a82f23d892552e146aa3f3e3646cb01e74055e5196ddbb711800dd7d135e0c74c
> 362
> 56fb3a4992478291cc33b7fe0d0362345166410d26fa71f393203ab0
> httpcomponents-core-5.1.4-src.zip httpcomponents-core-5.1.4-src.zip
> 9a94bad22f8d6757a3d5effce73e81279c45176eaa265404476878d48204365db4c04
> 638
> f1f732e8e3e6a03d0ad1c3cf895649cb33eb249b3e89b2846fabda6e
> httpcomponents-core-5.1.4-src.tar.gz httpcomponents-core-5.1.4-
> src.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpcore/KEYS
> 
> -
> --
> ---
> Vote: HttpCore 5.1.4 release
> [ ] +1 Release the packages as HttpCore 5.1.4.
> [ ] -1 I am against releasing the packages (must include a reason).
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 


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

[VOTE] Release HttpCore 5.1.4 based on RC1

[Oleg Kalnichevski]

Please vote on releasing these packages as HttpCore 5.1.4.
The vote is open for the at least 72 hours, and only votes from
HttpComponents PMC members are binding. The vote passes if at least
three binding +1 votes are cast and there are more +1 than -1 votes.

Release notes:
https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.1.4-RC1/RELEASE_NOTES-5.1.x.txt

Maven artefacts:
https://repository.apache.org/content/repositories/orgapachehttpcomponents-1149/org/apache/httpcomponents/core5/

Git Tag: 5.1.4-RC1
 https://github.com/apache/httpcomponents-core/tree/5.1.4-RC1

Packages:
https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.1.4-RC1
 revision 55418

Hashes:
6c842ed09007b0e54c50acb02c0b76de0845590f42e50721e1b6825a2e6838384a83a933
44599ad5cc1bb0f97e6d2b992e1ea303cbed582fc0f6642c27ba4758
httpcomponents-core-5.1.4-bin.zip httpcomponents-core-5.1.4-bin.zip
0cdc34fac5f48db0da136888d1b62950fb61e8d802d2d13b0f99b351b20552cc9d9042bc
3549682a908d50eff8ce2eb6193dea1fadd22c408acd4792e7892f73
httpcomponents-core-5.1.4-bin.tar.gz httpcomponents-core-5.1.4-
bin.tar.gz
7739a82f23d892552e146aa3f3e3646cb01e74055e5196ddbb711800dd7d135e0c74c362
56fb3a4992478291cc33b7fe0d0362345166410d26fa71f393203ab0
httpcomponents-core-5.1.4-src.zip httpcomponents-core-5.1.4-src.zip
9a94bad22f8d6757a3d5effce73e81279c45176eaa265404476878d48204365db4c04638
f1f732e8e3e6a03d0ad1c3cf895649cb33eb249b3e89b2846fabda6e
httpcomponents-core-5.1.4-src.tar.gz httpcomponents-core-5.1.4-
src.tar.gz

Keys:
 https://www.apache.org/dist/httpcomponents/httpcore/KEYS

---
---
Vote: HttpCore 5.1.4 release
[ ] +1 Release the packages as HttpCore 5.1.4.
[ ] -1 I am against releasing the packages (must include a reason).


-
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=17561333#comment-17561333
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-2163:
---

[~ashokpanghal] It has been a while since the last release but there have been 
no changes since 4.5.13 that really warrant a release including this one. No 
plans yet. Maybe toward the end of the summer.

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.10#820010)

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

HttpCore 5.1.4 release notes

[Oleg Kalnichevski]

Folks

Please review and amend the HttpCore 5.1.4 release notes

https://github.com/apache/httpcomponents-core/blob/5.1.x/RELEASE_NOTES.txt

That would also be the right moment to see if all test cases on the
5.1.x branch pass for your locally.

Oleg

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

HttpCore 5.1.4 release soon?

[Oleg Kalnichevski]

Folks

Will there be enough of us online to cut a new HttpCore 5.1 release
this week?

Oleg

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

[jira] [Resolved] (HTTPCORE-717) High CPU usage when client sends a request with invalid protocol

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-717.

Resolution: Duplicate

This issue has essentially the same root cause as HTTPCORE-716 and it is 
corrected by HTTPCORE-716 changes.

Oleg

> High CPU usage when client sends a request with invalid protocol
> 
>
> Key: HTTPCORE-717
> URL: https://issues.apache.org/jira/browse/HTTPCORE-717
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HttpNIOTestServer.jar, HttpNIOTestServer.zip, testclient 
> 2.zip, testclient.jar
>
>
> In httpCore NIO v4.4.15, we can observe a CPU spinning condition when the 
> client sends a request with an invalid protocol header. We have attached a 
> sample HTTP server and a client to reproduce this issue in JDK v1.8.0-272. 
> Could you please look into this?
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-716:


[~sanojpunchihewa] I came up with a better solution that should also fix 
HTTPCORE-717. Please review / test:

[https://github.com/apache/httpcomponents-core/commit/88ae6598f0b5903e12d00a394f18578aa83f0d68]

Oleg

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.jar, 
> HttpNIOTestServer.zip, HttpNIOTestServer2.zip, testclient 2.zip, 
> testclient.jar
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-716:


[~sanojpunchihewa] Please find the proposed fix here:

[https://github.com/apache/httpcomponents-core/commit/bc58e4edfb75304302c3470fa901b831f3f74a53]

Please test it with your local environment and confirm that the issue has been 
resolved for you.

Please also note that GET with enclosed request bodies are {_}crazy{_}. 
HttpCore 4.4.x treats them as illegal.

Oleg

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.jar, 
> HttpNIOTestServer.zip, HttpNIOTestServer2.zip, testclient 2.zip, 
> testclient.jar
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-716:


[~sanojpunchihewa] I can reproduce the defect in my environment and am working 
on a fix.

Oleg

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.jar, 
> HttpNIOTestServer.zip, HttpNIOTestServer2.zip, testclient 2.zip, 
> testclient.jar
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2222) ProtocolNegotiationException and ConnectionClosedException with httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-.
---
Fix Version/s: 5.1.4
   Resolution: Fixed

PR merged to 5.1.x.

> ProtocolNegotiationException and ConnectionClosedException with httpclient5
> ---
>
> Key: HTTPCLIENT-
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.1.3
> Environment: GNU/Linux 5.4 with JDK11.
>Reporter: Gaojie Liu
>Priority: Major
> Fix For: 5.1.4
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> We are using httpclient5 to talk HTTP/2 to a Netty H2 server and we are using 
> a pretty standard way to construct a HttpClient5 client as follows:
> {code:java}
> final IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setTcpNoDelay(true)
> .setSoTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> .setIoThreadCount(ioThreadCount)
> .build();
> final TlsStrategy tlsStrategy = skipCipherCheck ?
> VeniceClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build()
> : ClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build();
> final CloseableHttpAsyncClient client = 
> HttpAsyncClients.customHttp2().setTlsStrategy(tlsStrategy)
> .setIOReactorConfig(ioReactorConfig)
> .setDefaultRequestConfig(RequestConfig.custom()
> 
> .setResponseTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectionRequestTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectTimeout(Timeout.ofMilliseconds(connectTimeOutInMilliseconds))
> .build())
> .build();
> client.start(); {code}
> When we deployed this to prod, we discovered the following exceptions in the 
> first 30 mins and later, it seems become more stable:
> {code:java}
> org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:568)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:212)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:193)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at java.lang.Thread.run(Thread.java:834) 
> [?:?]org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
>         at 
> org.apache.hc.core5.http2.impl.nio.H2OnlyClientProtocolNegotiator.inputReady(H2OnlyClientProtocolNegotiator.java:133)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:549)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
>  ~[h

[jira] [Commented] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-716:


[~sanojpunchihewa] I will see if I can reproduce the defect locally and will 
get back to you.

Oleg

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.jar, 
> HttpNIOTestServer.zip, HttpNIOTestServer2.zip, testclient 2.zip, 
> testclient.jar
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2222) ProtocolNegotiationException and ConnectionClosedException with httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-:
---

[~Gaojie_Liu] 

> I have figured out the root cause of the `ConnectionClosedException` with 
> 5.1.2 and it was caused by the too short connectTimeout setting specified in 
> my application, and increasing it fixed these unexpected exceptions.

This makes no sense. Timeout setting can cause `SocketTimeoutException`. I do 
not see how an aggressive connect timeout could lead to a 
`ConnectionClosedException`.

> I am wondering whether you could back-port this fix from 5.2 to 5.1 to 
> release a new version: 5.1.4 or not.

_All_ bug fixes _always_ get back-ported. I am not sure what bug fix you are 
referring to.

> I will be very happy to do that if this won't violate the release philosophy 
> of httpclient5.

You are welcome to propose changes to 5.1.x branch but this particular case you 
should rather look at the problem on the server side, not on the client.

I will have to close this issue as invalid if there is no reproducer of the 
defect or at least a specific description of what HttpClient does incorrectly.

Oleg

 

> ProtocolNegotiationException and ConnectionClosedException with httpclient5
> ---
>
> Key: HTTPCLIENT-
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.1.3
> Environment: GNU/Linux 5.4 with JDK11.
>Reporter: Gaojie Liu
>Priority: Major
>
> We are using httpclient5 to talk HTTP/2 to a Netty H2 server and we are using 
> a pretty standard way to construct a HttpClient5 client as follows:
> {code:java}
> final IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setTcpNoDelay(true)
> .setSoTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> .setIoThreadCount(ioThreadCount)
> .build();
> final TlsStrategy tlsStrategy = skipCipherCheck ?
> VeniceClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build()
> : ClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build();
> final CloseableHttpAsyncClient client = 
> HttpAsyncClients.customHttp2().setTlsStrategy(tlsStrategy)
> .setIOReactorConfig(ioReactorConfig)
> .setDefaultRequestConfig(RequestConfig.custom()
> 
> .setResponseTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectionRequestTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectTimeout(Timeout.ofMilliseconds(connectTimeOutInMilliseconds))
> .build())
> .build();
> client.start(); {code}
> When we deployed this to prod, we discovered the following exceptions in the 
> first 30 mins and later, it seems become more stable:
> {code:java}
> org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:568)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:212)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:193)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at java.lang.Thread.run(Thread.java:834) 
> [?:?]

[jira] [Commented] (HTTPCLIENT-2224) US_ASCII used instead of charset configuration in CharCodingConfig

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2224:
---

[~javedbhayla] If you use Jackson as your JSON processor you might this project 
useful [1]. Disclaimer: I am a maintainer of that project.

[1]https://github.com/ok2c/httpcomponents-jackson

> US_ASCII used instead of charset configuration in CharCodingConfig
> --
>
> Key: HTTPCLIENT-2224
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2224
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3
> Environment: Running on MacOS, EC2
>Reporter: Javed Bhayla
>Priority: Major
>
> Issue: “supplémentaires sur l'état relative à” shows up as “suppl��mentaires 
> sur l'��tat relative ��” in the JSON response
> I have configured the async client to use UTF_8 using:
> CloseableHttpAsyncClient client = HttpAsyncClients.custom()
> .setCharCodingConfig(CharCodingConfig.custom().setCharset(UTF_8).build())
> .build()
> Making a request and calling “response.getBodyText()” results in US_ASCII 
> being used instead of UTF_8 because the server returns the header 
> “Content-Type: application/json” without the charset.
> If the server returns "Content-Type: application/json;charset=utf-8", then 
> UTF-8 is used as expected.
> Should the CharCodingConfig setting be used as the default instead of 
> US_ASCII in SimpleBody?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-716.

Resolution: Duplicate

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.zip
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-716:


[~sanojpunchihewa]
 # Your test code is based on 4.4.14, not 4.4.15. 
 # The description of the issue matches HTTPCORE-687 almost one to one
 # I do not know what postman is. I have no means of reproducing the issue 
locally. Please provide a test client (based on JRE or curl executable)
 # I will close the issue as duplicate shortly. Please do not reopen it until 
there is a reproducer based on 4.4.15

Oleg

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.zip
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCORE-716) High CPU usage noticed for HTTPS GET requests with large payload

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-716.

Resolution: Duplicate

Please upgrade to 4.4.15. This is a duplicate of  HTTPCORE-687.

Oleg

> High CPU usage noticed for HTTPS GET requests with large payload
> 
>
> Key: HTTPCORE-716
> URL: https://issues.apache.org/jira/browse/HTTPCORE-716
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.14, 4.4.15
>Reporter: Sanoj Punchihewa
>Priority: Major
> Attachments: HTTPCORE.postman_collection.json, HttpNIOTestServer.zip
>
>
> We are using 4.4.14 of HttpCore NIO. We are having an issue while sending an 
> *HTTPS GET* request to the server with a large payload where the CPU usage 
> seems to increase and stays on forever. We debugged and found out that after 
> the HTTPS response is written back to the client, the server tries to close 
> the connection. We found out that the condition [1] which gets executed in 
> order to make the state closed becomes false forever and hence it keeps on 
> trying to close. It was observed that inPlain.hasData() is always true.
> We have attached a sample POSTMAN request and a server in order to reproduce 
> the issue.
> Appreciate your help on this issue.
> [1]-[https://github.com/apache/httpcomponents-core/blob/rel/v4.4.14/httpcore-nio/src/main/java/org/apache/http/nio/reactor/ssl/SSLIOSession.java#L388]
> Thanks,
> Sanoj



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2224) US_ASCII used instead of charset configuration in CharCodingConfig

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2224:
---

[~javedbhayla] I am not sure 
[HTTPCLIENT-2159|https://issues.apache.org/jira/projects/HTTPCLIENT/issues/HTTPCLIENT-2159]
 is valid bit I leave it up to [~michael-o] to propose a fix.

I am not sure what you expect us to do here. Use a better message consumer 
optimized for processing of JSON messages. Simple messages are intended for 
trivial text message exchanges only.

https://hc.apache.org/httpcomponents-client-5.1.x/migration-guide/index.html

Oleg

> US_ASCII used instead of charset configuration in CharCodingConfig
> --
>
> Key: HTTPCLIENT-2224
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2224
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3
> Environment: Running on MacOS, EC2
>Reporter: Javed Bhayla
>Priority: Major
>
> Issue: “supplémentaires sur l'état relative à” shows up as “suppl��mentaires 
> sur l'��tat relative ��” in the JSON response
> I have configured the async client to use UTF_8 using:
> CloseableHttpAsyncClient client = HttpAsyncClients.custom()
> .setCharCodingConfig(CharCodingConfig.custom().setCharset(UTF_8).build())
> .build()
> Making a request and calling “response.getBodyText()” results in US_ASCII 
> being used instead of UTF_8 because the server returns the header 
> “Content-Type: application/json” without the charset.
> If the server returns "Content-Type: application/json;charset=utf-8", then 
> UTF-8 is used as expected.
> Should the CharCodingConfig setting be used as the default instead of 
> US_ASCII in SimpleBody?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2224) US_ASCII used instead of charset configuration in CharCodingConfig

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2224.
---
Resolution: Invalid

`CharCodingConfig` allies to HTTP/1.1 connection encoding (message headers and 
trailers). This configuration has no bearing on message content encoding, which 
is governed by `Content-Type` header.

Oleg

> US_ASCII used instead of charset configuration in CharCodingConfig
> --
>
> Key: HTTPCLIENT-2224
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2224
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3
> Environment: Running on MacOS, EC2
>Reporter: Javed Bhayla
>Priority: Major
>
> Issue: “supplémentaires sur l'état relative à” shows up as “suppl��mentaires 
> sur l'��tat relative ��” in the JSON response
> I have configured the async client to use UTF_8 using:
> CloseableHttpAsyncClient client = HttpAsyncClients.custom()
> .setCharCodingConfig(CharCodingConfig.custom().setCharset(UTF_8).build())
> .build()
> Making a request and calling “response.getBodyText()” results in US_ASCII 
> being used instead of UTF_8 because the server returns the header 
> “Content-Type: application/json” without the charset.
> If the server returns "Content-Type: application/json;charset=utf-8", then 
> UTF-8 is used as expected.
> Should the CharCodingConfig setting be used as the default instead of 
> US_ASCII in SimpleBody?



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-715) Website at https://hc.apache.org lacks maven links to source code

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-715:


[~minfrin]`git.apache.org` should be a pretty safe guess. Anyway, the URL could 
be corrected in the process of the PR review. 

Oleg

> Website at https://hc.apache.org lacks maven links to source code
> -
>
> Key: HTTPCORE-715
> URL: https://issues.apache.org/jira/browse/HTTPCORE-715
> Project: HttpComponents HttpCore
>  Issue Type: Wish
>  Components: Documentation
>Reporter: Graham Leggett
>Priority: Minor
>
> The authoritative links to the source code are missing from the maven 
> generated site.
> I can see mention of the github mirror under "getting involved", but nothing 
> about the authoritative source.
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

Re: HttpClient + system properties + client certificates - how?

[Oleg Kalnichevski]

On Sat, 2022-06-11 at 11:24 +0200, Graham Leggett wrote:
> Hi all,
> 
> I am trying to pick apart why jackrabbit is ignoring system
> parameters when using SSL.
> 
> According to the javadocs for
> https://www.javadoc.io/doc/org.apache.httpcomponents/httpclient/4.4/org/apache/http/impl/client/HttpClientBuilder.html
>  "System properties will be taken into account when configuring the
> default implementations when useSystemProperties() method is called
> prior to calling build().”
> 
> The code in jackrabbit looks like this:
> 
> https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-spi2dav/src/main/java/org/apache/jackrabbit/spi2dav/RepositoryServiceImpl.java#L365
> 
>     // request config
>     RequestConfig requestConfig = RequestConfig.custom().
>    
> setConnectTimeout(connectionOptions.getConnectionTimeoutMs()).
>    
> setConnectionRequestTimeout(connectionOptions.getRequestTimeoutMs()).
>    
> setSocketTimeout(connectionOptions.getSocketTimeoutMs()).build();
>     hcb.setDefaultRequestConfig(requestConfig);
>     if
> (Boolean.getBoolean("jackrabbit.client.useSystemProperties") ||
> connectionOptions.isUseSystemPropertes()) {
>     log.debug("Using system properties for establishing
> connection!");
>     // support Java system proxy? (JCR-3211)
>     hcb.useSystemProperties();
>     }
> 
> In theory, the above should cause (when properly config’ed) system
> properties to be used.
> 
> We then do this:
> 
>     // TLS settings (via connection manager)
>     final SSLContext sslContext;
>     try {
>     if (connectionOptions.isAllowSelfSignedCertificates()) {
>     log.warn("Nonsecure TLS setting: Accepting self-
> signed certificates!");
>     sslContext =
> SSLContextBuilder.create().loadTrustMaterial(new
> TrustSelfSignedStrategy()).build();
>     hcb.setSSLContext(sslContext);
> 
> Am I right in understanding that the above will override the system
> properties and create an SSL context that contains no key material
> from system properties?

No, you are not. HttpClient will trust certificates with a single self-
signed certificate in the cert chain but all other certificates (with
two or more signators in the cert chain) will still be verified by the
default trust manager.

> 
>     } else {
>     sslContext = SSLContextBuilder.create().build();
> 
> Am I also correct in understanding that
> SSLContextBuilder.create().build() above will create a context with
> no key material, ignoring the system properties?
> 

You are correct. However, trust material shipped with the JRE will be
loaded by default (this is not by design, this is how Oracle JSSE
provider behaves). That is, standard CAs will be trusted by default.

>     }
>     } catch (KeyManagementException | NoSuchAlgorithmException |
> KeyStoreException e) {
>     throw new RepositoryException(e);
>     }
>     final SSLConnectionSocketFactory sslSocketFactory;
>     if (connectionOptions.isDisableHostnameVerification()) {
>     log.warn("Nonsecure TLS setting: Host name verification
> of TLS certificates disabled!");
>     // we can optionally disable hostname verification.
>     sslSocketFactory = new
> SSLConnectionSocketFactory(sslContext,
> NoopHostnameVerifier.INSTANCE);
>     } else {
>     sslSocketFactory = new
> SSLConnectionSocketFactory(sslContext);
>     }
>     
>     Registry socketFactoryRegistry =
> RegistryBuilder.create()
>     .register("http",
> PlainConnectionSocketFactory.getSocketFactory())
>     .register("https", sslSocketFactory)
>     .build();
> 
> I am trying to work out what changes I need to be above code to make
> this support system properties by default, and then apply changes to
> the system defaults where coded to do so.
> 
> Regards,
> Graham
> —
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 


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

Re: org.apache.http.client.methods.HttpEntityEnclosingRequestBase removed - what replaced it?

[Oleg Kalnichevski]

On Sat, 2022-06-11 at 10:30 +0200, Graham Leggett wrote:
> Hi all,
> 
> I am looking at how feasible it is to upgrade jackrabbit from
> httpclient 4 to 5, and have found that the following class was
> removed in trunk:
> 
> org.apache.http.client.methods.HttpEntityEnclosingRequestBase
> 
> There is nothing in the javadocs for 4.x to show that the class is
> deprecated or what it’s been replaced with, can anyone confirm what
> replaces this class?
> 
> https://github.com/apache/jackrabbit/blob/ed3124e5fe223dada33ce6ddf53bc666063c3f2f/jackrabbit-webdav/src/main/java/org/apache/jackrabbit/webdav/client/methods/BaseDavRequest.java#L47
> 
> Regards,
> Graham

Hi Graham

As of version 5.0 all HTTP methods can include a message context body. 

For more details please see:

https://hc.apache.org/httpcomponents-client-5.1.x/migration-guide/migration-to-classic.html

Oleg

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

[jira] [Commented] (HTTPCORE-715) Website at https://hc.apache.org lacks maven links to source code

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-715:


[~minfrin] You can submit changes to the project web site you are proposing by 
raising a PR at GitHub for this project:

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

Oleg

> Website at https://hc.apache.org lacks maven links to source code
> -
>
> Key: HTTPCORE-715
> URL: https://issues.apache.org/jira/browse/HTTPCORE-715
> Project: HttpComponents HttpCore
>  Issue Type: Wish
>  Components: Documentation
>Reporter: Graham Leggett
>Priority: Minor
>
> The authoritative links to the source code are missing from the maven 
> generated site.
> I can see mention of the github mirror under "getting involved", but nothing 
> about the authoritative source.
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Updated] (HTTPCORE-715) Website at https://hc.apache.org lacks maven links to source code

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski updated HTTPCORE-715:
---
Component/s: Documentation
 Issue Type: Wish  (was: Bug)
   Priority: Minor  (was: Major)

> Website at https://hc.apache.org lacks maven links to source code
> -
>
> Key: HTTPCORE-715
> URL: https://issues.apache.org/jira/browse/HTTPCORE-715
> Project: HttpComponents HttpCore
>  Issue Type: Wish
>  Components: Documentation
>Reporter: Graham Leggett
>Priority: Minor
>
> The authoritative links to the source code are missing from the maven 
> generated site.
> I can see mention of the github mirror under "getting involved", but nothing 
> about the authoritative source.
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2221) Differences between HttpEntity.close() and HttpEntity.getContent().close()

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2221.
---
Fix Version/s: 4.5.14
   5.2-beta2
   Resolution: Fixed

Committed to master and 5.1.x.

Oleg

> Differences between HttpEntity.close() and HttpEntity.getContent().close()
> --
>
> Key: HTTPCLIENT-2221
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2221
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.1.3
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
> Fix For: 4.5.14, 5.2-beta2
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> My assumption is that closing an entity should have the same behavior as 
> closing the entity.getContent() inputstream.
> Given a streaming response, calling HttpEntity.close doesn't handle 
> connection management pieces (interactions with the {{ExecRuntime}}) because 
> {{ResponseEntityProxy}} wraps {{getContent}} and {{writeTo}}, however it does 
> not override the {{close}} implementation inherited from 
> {{HttpEntityWrapper}}.
> In practice, this may mean that calling HttpEntity.close instead of consuming 
> the contents doesn't return the connection to the pool, or in my case, 
> calling CloseableHttpResponse.close results in 
> {{execRuntime.disconnectEndpoint();}} after the entity has been drained 
> within its own close, however the connection is still closed.
> I think we want to make either one of the following changes:
> 1. HttpEntity.close() provides the same behavior as 
> HttpEntity.getContent().close(), draining the response (which we already do) 
> and returning the connection for reuse
> 2. HttpEntity.close() does not read the full response, closing it 
> immediately. I think I'd prefer to avoid this approach given that much of our 
> code assumes close leaves a connection in a reusable state.
> Separately, it may be helpful to provide a strategy interface to allow for 
> more specific handling of connection closure prior to exhaustion of bytes. 
> The current strategy of draining the full response is ideal in most 
> scenarios, however after a certain amount of additional data, we may be 
> better off closing the connection. I suspect part of the issue in this case 
> is that we seem to expect subtly different behavior between 
> {{CloseableHttpResponse.close}} and 
> {{EntityUtils.consume(response.getEntity())}}.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2222) ProtocolNegotiationException and ConnectionClosedException with httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-:
---

[~Gaojie_Liu] By the way, (I should have mentioned it from the very beginning) 
`ConnectionClosedException`s are perfectly normal. It is perfectly valid for 
HTTP endpoints to drop the connection at any point of time if they choose to do 
so. The only potential issue there can be that HttpClient for some reason fails 
to retry requests automatically in case of ConnectionClosedException.

Oleg

> ProtocolNegotiationException and ConnectionClosedException with httpclient5
> ---
>
> Key: HTTPCLIENT-
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.1.3
> Environment: GNU/Linux 5.4 with JDK11.
>Reporter: Gaojie Liu
>Priority: Major
>
> We are using httpclient5 to talk HTTP/2 to a Netty H2 server and we are using 
> a pretty standard way to construct a HttpClient5 client as follows:
> {code:java}
> final IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setTcpNoDelay(true)
> .setSoTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> .setIoThreadCount(ioThreadCount)
> .build();
> final TlsStrategy tlsStrategy = skipCipherCheck ?
> VeniceClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build()
> : ClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build();
> final CloseableHttpAsyncClient client = 
> HttpAsyncClients.customHttp2().setTlsStrategy(tlsStrategy)
> .setIOReactorConfig(ioReactorConfig)
> .setDefaultRequestConfig(RequestConfig.custom()
> 
> .setResponseTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectionRequestTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectTimeout(Timeout.ofMilliseconds(connectTimeOutInMilliseconds))
> .build())
> .build();
> client.start(); {code}
> When we deployed this to prod, we discovered the following exceptions in the 
> first 30 mins and later, it seems become more stable:
> {code:java}
> org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:568)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:212)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:193)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at java.lang.Thread.run(Thread.java:834) 
> [?:?]org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
>         at 
> org.apache.hc.core5.http2.impl.nio.H2OnlyClientProtocolNegotiator.inputReady(H2OnlyClientProtocolNegotiator.java:133)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:549)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
>  ~[httpcore5-5.1.2.jar:5.

[jira] [Comment Edited] (HTTPCLIENT-2222) ProtocolNegotiationException and ConnectionClosedException with httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski edited comment on HTTPCLIENT- at 6/11/22 11:46 AM:
-

[~Gaojie_Liu] Please do the following:
 # Upgrade HttpCore to the _latest_ 5.1.x snapshot.  Build it from source.
 # Make your application use the latest HttpCore snapshot instead of the one 
shipped with HttpClient
 # Turn on wire / context logging
 # Reproduce the issue locally
 # Redact whatever sensitive stuff there might be in the log
 # Attach it to this issue.

Oleg


was (Author: olegk):
[~Gaojie_Liu] Please do the following:
 # Upgrade HttpCore to the _latest_ 5.1.x snapshot.  Build it from source.
 # Turn on wire / context logging
 # Reproduce the issue locally
 # Redact whatever sensitive stuff there might be in the log
 # Attach it to this issue.

Oleg

> ProtocolNegotiationException and ConnectionClosedException with httpclient5
> ---
>
> Key: HTTPCLIENT-
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.1.3
> Environment: GNU/Linux 5.4 with JDK11.
>Reporter: Gaojie Liu
>Priority: Major
>
> We are using httpclient5 to talk HTTP/2 to a Netty H2 server and we are using 
> a pretty standard way to construct a HttpClient5 client as follows:
> {code:java}
> final IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setTcpNoDelay(true)
> .setSoTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> .setIoThreadCount(ioThreadCount)
> .build();
> final TlsStrategy tlsStrategy = skipCipherCheck ?
> VeniceClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build()
> : ClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build();
> final CloseableHttpAsyncClient client = 
> HttpAsyncClients.customHttp2().setTlsStrategy(tlsStrategy)
> .setIOReactorConfig(ioReactorConfig)
> .setDefaultRequestConfig(RequestConfig.custom()
> 
> .setResponseTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectionRequestTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectTimeout(Timeout.ofMilliseconds(connectTimeOutInMilliseconds))
> .build())
> .build();
> client.start(); {code}
> When we deployed this to prod, we discovered the following exceptions in the 
> first 30 mins and later, it seems become more stable:
> {code:java}
> org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:568)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:212)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:193)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at java.lang.Thread.run(Thread.java:834) 
> [?:?]org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
>         at 
> org.apache.hc.core5.http2.impl.nio.H2OnlyClientProtocolNegotiator.inputReady(H2OnlyClientProtocolNegotiator.java:133)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIO

[jira] [Commented] (HTTPCLIENT-2222) ProtocolNegotiationException and ConnectionClosedException with httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-:
---

[~Gaojie_Liu] Please do the following:
 # Upgrade HttpCore to the _latest_ 5.1.x snapshot.  Build it from source.
 # Turn on wire / context logging
 # Reproduce the issue locally
 # Redact whatever sensitive stuff there might be in the log
 # Attach it to this issue.

Oleg

> ProtocolNegotiationException and ConnectionClosedException with httpclient5
> ---
>
> Key: HTTPCLIENT-
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.1.3
> Environment: GNU/Linux 5.4 with JDK11.
>Reporter: Gaojie Liu
>Priority: Major
>
> We are using httpclient5 to talk HTTP/2 to a Netty H2 server and we are using 
> a pretty standard way to construct a HttpClient5 client as follows:
> {code:java}
> final IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setTcpNoDelay(true)
> .setSoTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> .setIoThreadCount(ioThreadCount)
> .build();
> final TlsStrategy tlsStrategy = skipCipherCheck ?
> VeniceClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build()
> : ClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build();
> final CloseableHttpAsyncClient client = 
> HttpAsyncClients.customHttp2().setTlsStrategy(tlsStrategy)
> .setIOReactorConfig(ioReactorConfig)
> .setDefaultRequestConfig(RequestConfig.custom()
> 
> .setResponseTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectionRequestTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectTimeout(Timeout.ofMilliseconds(connectTimeOutInMilliseconds))
> .build())
> .build();
> client.start(); {code}
> When we deployed this to prod, we discovered the following exceptions in the 
> first 30 mins and later, it seems become more stable:
> {code:java}
> org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:568)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:212)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:193)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at java.lang.Thread.run(Thread.java:834) 
> [?:?]org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
>         at 
> org.apache.hc.core5.http2.impl.nio.H2OnlyClientProtocolNegotiator.inputReady(H2OnlyClientProtocolNegotiator.java:133)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:549)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
>  ~[httpcore5-5

[jira] [Commented] (HTTPCLIENT-2221) Differences between HttpEntity.close() and HttpEntity.getContent().close()

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2221:
---

[~ckozak] Sounds reasonable. Feel free to raise a PR with proposed changes.

Oleg

> Differences between HttpEntity.close() and HttpEntity.getContent().close()
> --
>
> Key: HTTPCLIENT-2221
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2221
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.1.3
>Reporter: Carter Kozak
>Assignee: Carter Kozak
>Priority: Major
>
> My assumption is that closing an entity should have the same behavior as 
> closing the entity.getContent() inputstream.
> Given a streaming response, calling HttpEntity.close doesn't handle 
> connection management pieces (interactions with the {{ExecRuntime}}) because 
> {{ResponseEntityProxy}} wraps {{getContent}} and {{writeTo}}, however it does 
> not override the {{close}} implementation inherited from 
> {{HttpEntityWrapper}}.
> In practice, this may mean that calling HttpEntity.close instead of consuming 
> the contents doesn't return the connection to the pool, or in my case, 
> calling CloseableHttpResponse.close results in 
> {{execRuntime.disconnectEndpoint();}} after the entity has been drained 
> within its own close, however the connection is still closed.
> I think we want to make either one of the following changes:
> 1. HttpEntity.close() provides the same behavior as 
> HttpEntity.getContent().close(), draining the response (which we already do) 
> and returning the connection for reuse
> 2. HttpEntity.close() does not read the full response, closing it 
> immediately. I think I'd prefer to avoid this approach given that much of our 
> code assumes close leaves a connection in a reusable state.
> Separately, it may be helpful to provide a strategy interface to allow for 
> more specific handling of connection closure prior to exhaustion of bytes. 
> The current strategy of draining the full response is ideal in most 
> scenarios, however after a certain amount of additional data, we may be 
> better off closing the connection. I suspect part of the issue in this case 
> is that we seem to expect subtly different behavior between 
> {{CloseableHttpResponse.close}} and 
> {{EntityUtils.consume(response.getEntity())}}.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2222) ProtocolNegotiationException and ConnectionClosedException with httpclient5

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-:
---

[~Gaojie_Liu] What is specifically the bug you are reporting? All I can see is 
that the opposite endpoint drops connections on HttpClient without returning a 
status code of any sort. I will have to close the issue as invalid unless you 
can provide a reproducer or a clear description of what you think HttpClient 
does incorrectly.

Oleg

 

> ProtocolNegotiationException and ConnectionClosedException with httpclient5
> ---
>
> Key: HTTPCLIENT-
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.2, 5.1.3
> Environment: GNU/Linux 5.4 with JDK11.
>Reporter: Gaojie Liu
>Priority: Major
>
> We are using httpclient5 to talk HTTP/2 to a Netty H2 server and we are using 
> a pretty standard way to construct a HttpClient5 client as follows:
> {code:java}
> final IOReactorConfig ioReactorConfig = IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setTcpNoDelay(true)
> .setSoTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> .setIoThreadCount(ioThreadCount)
> .build();
> final TlsStrategy tlsStrategy = skipCipherCheck ?
> VeniceClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build()
> : ClientTlsStrategyBuilder.create()
> .setSslContext(sslContext)
> .setTlsVersions(TLS.V_1_3, TLS.V_1_2)
> .build();
> final CloseableHttpAsyncClient client = 
> HttpAsyncClients.customHttp2().setTlsStrategy(tlsStrategy)
> .setIOReactorConfig(ioReactorConfig)
> .setDefaultRequestConfig(RequestConfig.custom()
> 
> .setResponseTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectionRequestTimeout(Timeout.ofMilliseconds(requestTimeOutInMilliseconds))
> 
> .setConnectTimeout(Timeout.ofMilliseconds(connectTimeOutInMilliseconds))
> .build())
> .build();
> client.start(); {code}
> When we deployed this to prod, we discovered the following exceptions in the 
> first 30 mins and later, it seems become more stable:
> {code:java}
> org.apache.hc.core5.http.ConnectionClosedException: Connection is closed
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2StreamMultiplexer.onDisconnect(AbstractH2StreamMultiplexer.java:568)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.AbstractH2IOEventHandler.disconnected(AbstractH2IOEventHandler.java:96)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.http2.impl.nio.ClientH2IOEventHandler.disconnected(ClientH2IOEventHandler.java:39)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.disconnected(SSLIOSession.java:212)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.InternalDataChannel.disconnected(InternalDataChannel.java:193)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processClosedSessions(SingleCoreIOReactor.java:231)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:133)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:85)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at java.lang.Thread.run(Thread.java:834) 
> [?:?]org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
>         at 
> org.apache.hc.core5.http2.impl.nio.H2OnlyClientProtocolNegotiator.inputReady(H2OnlyClientProtocolNegotiator.java:133)
>  ~[httpcore5-h2-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:549)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72) 
> ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
>  ~[httpcore5-5.1.2.jar:5.1.2]
>         at 
> org.apache

[ANNOUNCEMENT] HttpComponents Client 5.2-beta1 Released

[Oleg Kalnichevski]

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

This is the first BETA release in the 5.2 release series that upgrades
minimal JRE level to version 8 (8u251 is required) and includes several
protocol level and API improvements. It also includes all bug fixes
from the 5.1 branch.

Notable changes and features included in the 5.2 series:

* Upgrade to Java 8.

* Improved support for TLS upgrade and HTTP protocol upgrade (async).

* Support for H2 tunneling via HTTP/1.1 proxy.

* Conformance to RFC 7617 (The 'Basic' HTTP Authentication Scheme).

* Migration to Java 8 Time primitives in State Management and Cache
APIs.

* Base64 codec based on Commons Codec replaced with JRE Base64 codec.
Dependency on Commons Codec dropped.

* Optional support for BR (Brotli) decompression.

Download - 
Release notes -


About HttpComponents HttpClient

The Hyper-Text Transfer Protocol (HTTP) is perhaps the most
significantprotocol used on the Internet today. Web services, network-
enabled appliances and the growth of network computing continue to
expand the role of the HTTP protocol beyond user-driven web browsers,
while increasing the number of applications that require HTTP support.

Although the java.net package provides basic functionality for
accessing resources via HTTP, it doesn't provide the full flexibility
or functionality needed by many applications. HttpClient seeks to fill
this voidby providing an efficient, up-to-date, and feature-rich
package implementing the client side of the most recent HTTP standards
and recommendations.

Designed for extension while providing robust support for the base
HTTPprotocol, HttpClient may be of interest to anyone building HTTP-
aware client applications such as web browsers, web service clients, or
systems that leverage or extend the HTTP protocol for distributed
communication.


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

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

[Oleg Kalnichevski]

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

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

no other votes

* binding votes
https://lists.apache.org/thread/4toyb41c75mrsoo3tsgp0bc7jfrhqj5q

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

Re: [VOTE] Release HttpClient 5.2-beta1 based on RC1

[Oleg Kalnichevski]

[x] +1 Release the packages as HttpClient 5.2-beta1

On Sat, 2022-06-04 at 00:18 +0200, Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.2-beta1.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and there are more +1 than -1 votes.
> 
> Release notes:
>  
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.2-
> beta1-RC1/RELEASE_NOTES-5.2.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcompon
> ents-1148/org/apache/httpcomponents/client5
> 
> Git Tag: 5.2-beta1-RC1
>  https://github.com/apache/httpcomponents-client/tree/5.2-beta1-RC1
> 
> Packages:
>  
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.2-
> beta1-RC1
>  revision 54850
> 
> Hashes:
>  09369a1b72fdb5c06c4615e3adb8782d68a44268ecc352cdcd4e8d6b27a94734b8a3
> d54c9c39d96e9daf7443bafa7e77b6010738b8a6b050935b743e52f5b1fb
> httpcomponents-client-5.2-beta1-bin.zip httpcomponents-client-5.2-
> beta1-bin.zip
>  e08dd2c278f4f79aacba4ab400efba8b1cc823092d79051c95d913b013ba88c8a4a4
> 25bc6d581b027601398f37c6bddba2782bf25546137e33a8bb6fe472c265
> httpcomponents-client-5.2-beta1-src.zip httpcomponents-client-5.2-
> beta1-src.zip
>  4fc081911df87fa193b1f365c28a0928bc5bffc18539af11a37633bda65649789f46
> 1baf47fd8db9df251c373aaacea9a8dcac68b634f219f0ca8d7afc838df7
> httpcomponents-client-5.2-beta1-bin.tar.gz httpcomponents-client-5.2-
> beta1-bin.tar.gz
>  aec16436e6adb7d5f1dd8b5d07c90883abb8cf14c2f4cb596a3a0e85ff2dbcc55ac3
> 46945eee38cc47139eb9790c31c64967054f687a004998113430bfdc0fd5
> httpcomponents-client-5.2-beta1-src.tar.gz httpcomponents-client-5.2-
> beta1-src.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpclient/KEYS
> 
> -
> -
> Vote: HttpClient 5.2-beta1 release
> [ ] +1 Release the packages as HttpClient 5.2-beta1.
> [ ] -1 I am against releasing the packages (must include a reason).
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 


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

[VOTE] Release HttpClient 5.2-beta1 based on RC1

[Oleg Kalnichevski]

Please vote on releasing these packages as HttpClient 5.2-beta1.
The vote is open for the at least 72 hours, and only votes from
HttpComponents PMC members are binding. The vote passes if at least
three binding +1 votes are cast and there are more +1 than -1 votes.

Release notes:
 
https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.2-beta1-RC1/RELEASE_NOTES-5.2.x.txt

Maven artefacts:
 
https://repository.apache.org/content/repositories/orgapachehttpcomponents-1148/org/apache/httpcomponents/client5

Git Tag: 5.2-beta1-RC1
 https://github.com/apache/httpcomponents-client/tree/5.2-beta1-RC1

Packages:
 https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.2-beta1-RC1
 revision 54850

Hashes:
 
09369a1b72fdb5c06c4615e3adb8782d68a44268ecc352cdcd4e8d6b27a94734b8a3d54c9c39d96e9daf7443bafa7e77b6010738b8a6b050935b743e52f5b1fb
 httpcomponents-client-5.2-beta1-bin.zip httpcomponents-client-5.2-beta1-bin.zip
 
e08dd2c278f4f79aacba4ab400efba8b1cc823092d79051c95d913b013ba88c8a4a425bc6d581b027601398f37c6bddba2782bf25546137e33a8bb6fe472c265
 httpcomponents-client-5.2-beta1-src.zip httpcomponents-client-5.2-beta1-src.zip
 
4fc081911df87fa193b1f365c28a0928bc5bffc18539af11a37633bda65649789f461baf47fd8db9df251c373aaacea9a8dcac68b634f219f0ca8d7afc838df7
 httpcomponents-client-5.2-beta1-bin.tar.gz 
httpcomponents-client-5.2-beta1-bin.tar.gz
 
aec16436e6adb7d5f1dd8b5d07c90883abb8cf14c2f4cb596a3a0e85ff2dbcc55ac346945eee38cc47139eb9790c31c64967054f687a004998113430bfdc0fd5
 httpcomponents-client-5.2-beta1-src.tar.gz 
httpcomponents-client-5.2-beta1-src.tar.gz

Keys:
 https://www.apache.org/dist/httpcomponents/httpclient/KEYS

--
Vote: HttpClient 5.2-beta1 release
[ ] +1 Release the packages as HttpClient 5.2-beta1.
[ ] -1 I am against releasing the packages (must include a reason).


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

[ANNOUNCEMENT] HttpComponents Core 5.2-beta2 released

[Oleg Kalnichevski]

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

This BETA release corrects a major regression in the TLS handshake
handling code introduced in the previous BETA release.

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

Please note that 5.2 upgrades the 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 8 date / time APIs

Download - 
Release notes -


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

HttpClient 5.2-beta2 release notes

[Oleg Kalnichevski]

Folks

Please review and amend HttpClient 5.2-beta2 release notes.

This would also be the right moment to test the latest build, report
test failures and propose release process improvements.

https://github.com/apache/httpcomponents-client/blob/master/RELEASE_NOTES.txt

Oleg

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

[jira] [Resolved] (HTTPCLIENT-2217) 5.1 Quick start link is dead

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2217.
---
Resolution: Fixed

Corrected.

Oleg

> 5.1 Quick start link is dead
> 
>
> Key: HTTPCLIENT-2217
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2217
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Documentation, Site
>Affects Versions: 5.1
>Reporter: Ng Tsz Sum
>Priority: Minor
>
> In [https://hc.apache.org/httpcomponents-client-5.1.x/quickstart.html]
> All link in 
> {code:java}
> Source can be found here{code}
> return 404
> e.g. 
> [https://github.com/apache/httpcomponents-client/tree/5.1.x/httpclient5/src/test/java/org/apache/hc/client5/http/examples/QuickStart.java]
> Where 
> [https://github.com/apache/httpcomponents-client/tree/5.1.x/httpclient5/src/test/java/org/apache/hc/client5/http/examples/|https://github.com/apache/httpcomponents-client/tree/5.1.x/httpclient5/src/test/java/org/apache/hc/client5/http/examples/QuickStart.java]
> is visible, but no file named QuickStart.java



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2219) Invalid protocol version when running different JDK versions

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2219.
---
Resolution: Information Provided

> Invalid protocol version when running different JDK versions
> 
>
> Key: HTTPCLIENT-2219
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2219
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3
>Reporter: Dillon Krompetz
>Priority: Minor
>
> NOTE: Not using Proxy
> In attempting to do a GET against a CloudFront resource I started to get 
> `Invalid protocol version` exceptions without using a Proxy (as other users 
> have faced as a known issue with this client). Strangely I am seeing this 
> issue when jumping between JDK versions. I noticed that the issue shows up 
> only when Negotiating Http protocol (Forcing to Http_1.1 or Http_2 works 
> perfectly fine).
> Lines of interest:
> SSLIOSession.java:545 is only called JDK 16+
> SSLIOSession.java:574
> BasicLineParser.java:103 buffer does not contain the expected "HTTP" protoname
> Issue detected on: 
> JDK 17.0.2 https://jdk.java.net/archive/
> JDK 16.0.2 https://jdk.java.net/archive/
> Working successfully on:
> JDK 15.0.2 [https://jdk.java.net/archive/]
> Reproduce:
> {code:java}
> import org.apache.hc.client5.http.async.methods.SimpleResponseConsumer 
> import org.apache.hc.client5.http.impl.async.HttpAsyncClients
> import org.apache.hc.core5.http.nio.support.AsyncRequestBuilder
> fun main() {
> val client = HttpAsyncClients.custom()
> //.setVersionPolicy(HttpVersionPolicy.FORCE_HTTP_2)
> .build()
> client.start()
> val requestProducer = AsyncRequestBuilder
> .create("GET")
> .setUri("https://www.google.com;)
> .build()
> val response = client.execute(
> requestProducer,
> SimpleResponseConsumer.create(),
> null,
> null
> ).get()
> println(response?.bodyText)
> }  
> {code}
> Exception:
> {code:java}
> Exception in thread "main" java.util.concurrent.ExecutionException: 
> org.apache.hc.core5.http.ParseException: Invalid protocol version; error at 
> offset 0: 
> <[0x2e][0x2f][0x30][0x31][0x32][0x33][0x34][0x35][0x36][0x37][0x38][0x39][0x3a][0x3b]d[0x3d][0x3e][0x3f][0x40][0x41][0x42][0x43][0x44][0x45][0x46][0x47][0x48][0x49][0x4a][0x4b][0x4c][0x4d][0x4e][0x4f][0x50][0x51][0x52][0x53][0x54][0x55][0x56][0x57][0x58][0x59][0x5a][0x5b][0x5c][0x5d][0x5e][0x5f][0x60][0x61][0x62][0x63][0x64][0x65][0x66]http2_handshake_failed>
> at 
> org.apache.hc.core5.concurrent.BasicFuture.getResult(BasicFuture.java:72)
> at org.apache.hc.core5.concurrent.BasicFuture.get(BasicFuture.java:85)at 
> MainKt.http5Client(Main.kt:41)at MainKt.main(Main.kt:21)at 
> MainKt.main(Main.kt)Caused by: org.apache.hc.core5.http.ParseException: 
> Invalid protocol version; error at offset 0: 
> <[0x2e][0x2f][0x30][0x31][0x32][0x33][0x34][0x35][0x36][0x37][0x38][0x39][0x3a][0x3b]d[0x3d][0x3e][0x3f][0x40][0x41][0x42][0x43][0x44][0x45][0x46][0x47][0x48][0x49][0x4a][0x4b][0x4c][0x4d][0x4e][0x4f][0x50][0x51][0x52][0x53][0x54][0x55][0x56][0x57][0x58][0x59][0x5a][0x5b][0x5c][0x5d][0x5e][0x5f][0x60][0x61][0x62][0x63][0x64][0x65][0x66]http2_handshake_failed>
> at 
> org.apache.hc.core5.http.message.BasicLineParser.parseProtocolVersion(BasicLineParser.java:110)
> at 
> org.apache.hc.core5.http.message.BasicLineParser.parseStatusLine(BasicLineParser.java:181)
> at 
> org.apache.hc.core5.http.impl.nio.DefaultHttpResponseParser.createMessage(DefaultHttpResponseParser.java:83)
> at 
> org.apache.hc.core5.http.impl.nio.DefaultHttpResponseParser.createMessage(DefaultHttpResponseParser.java:44)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractMessageParser.parseHeadLine(AbstractMessageParser.java:115)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractMessageParser.parse(AbstractMessageParser.java:167)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractMessageParser.parse(AbstractMessageParser.java:51)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.parseMessageHead(AbstractHttp1StreamDuplexer.java:256)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1StreamDuplexer.onInput(AbstractHttp1StreamDuplexer.java:285)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractHttp1IOEventHandler.inputReady(AbstractHttp1IOEventHandler.java:64)
> at 
> org.apache.hc.

[jira] [Commented] (HTTPCLIENT-2219) Invalid protocol version when running different JDK versions

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2219:
---

[~dkrompet] Due to Java 1.7 compatibility by default HttpClient 5.1 makes use 
of reflective access to ALPN protocol details. As of Java 16 reflective access 
to Java Platform APIs is considered illegal and is denied by the JRE security 
manager.  You need to provide a custom TLS detail factory as demonstrated here:

[https://github.com/apache/httpcomponents-client/blob/5.1.x/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientTlsAlpn.java]

Oleg

> Invalid protocol version when running different JDK versions
> 
>
> Key: HTTPCLIENT-2219
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2219
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3
>Reporter: Dillon Krompetz
>Priority: Minor
>
> NOTE: Not using Proxy
> In attempting to do a GET against a CloudFront resource I started to get 
> `Invalid protocol version` exceptions without using a Proxy (as other users 
> have faced as a known issue with this client). Strangely I am seeing this 
> issue when jumping between JDK versions. I noticed that the issue shows up 
> only when Negotiating Http protocol (Forcing to Http_1.1 or Http_2 works 
> perfectly fine).
> Lines of interest:
> SSLIOSession.java:545 is only called JDK 16+
> SSLIOSession.java:574
> BasicLineParser.java:103 buffer does not contain the expected "HTTP" protoname
> Issue detected on: 
> JDK 17.0.2 https://jdk.java.net/archive/
> JDK 16.0.2 https://jdk.java.net/archive/
> Working successfully on:
> JDK 15.0.2 [https://jdk.java.net/archive/]
> Reproduce:
> {code:java}
> import org.apache.hc.client5.http.async.methods.SimpleResponseConsumer 
> import org.apache.hc.client5.http.impl.async.HttpAsyncClients
> import org.apache.hc.core5.http.nio.support.AsyncRequestBuilder
> fun main() {
> val client = HttpAsyncClients.custom()
> //.setVersionPolicy(HttpVersionPolicy.FORCE_HTTP_2)
> .build()
> client.start()
> val requestProducer = AsyncRequestBuilder
> .create("GET")
> .setUri("https://www.google.com;)
> .build()
> val response = client.execute(
> requestProducer,
> SimpleResponseConsumer.create(),
> null,
> null
> ).get()
> println(response?.bodyText)
> }  
> {code}
> Exception:
> {code:java}
> Exception in thread "main" java.util.concurrent.ExecutionException: 
> org.apache.hc.core5.http.ParseException: Invalid protocol version; error at 
> offset 0: 
> <[0x2e][0x2f][0x30][0x31][0x32][0x33][0x34][0x35][0x36][0x37][0x38][0x39][0x3a][0x3b]d[0x3d][0x3e][0x3f][0x40][0x41][0x42][0x43][0x44][0x45][0x46][0x47][0x48][0x49][0x4a][0x4b][0x4c][0x4d][0x4e][0x4f][0x50][0x51][0x52][0x53][0x54][0x55][0x56][0x57][0x58][0x59][0x5a][0x5b][0x5c][0x5d][0x5e][0x5f][0x60][0x61][0x62][0x63][0x64][0x65][0x66]http2_handshake_failed>
> at 
> org.apache.hc.core5.concurrent.BasicFuture.getResult(BasicFuture.java:72)
> at org.apache.hc.core5.concurrent.BasicFuture.get(BasicFuture.java:85)at 
> MainKt.http5Client(Main.kt:41)at MainKt.main(Main.kt:21)at 
> MainKt.main(Main.kt)Caused by: org.apache.hc.core5.http.ParseException: 
> Invalid protocol version; error at offset 0: 
> <[0x2e][0x2f][0x30][0x31][0x32][0x33][0x34][0x35][0x36][0x37][0x38][0x39][0x3a][0x3b]d[0x3d][0x3e][0x3f][0x40][0x41][0x42][0x43][0x44][0x45][0x46][0x47][0x48][0x49][0x4a][0x4b][0x4c][0x4d][0x4e][0x4f][0x50][0x51][0x52][0x53][0x54][0x55][0x56][0x57][0x58][0x59][0x5a][0x5b][0x5c][0x5d][0x5e][0x5f][0x60][0x61][0x62][0x63][0x64][0x65][0x66]http2_handshake_failed>
> at 
> org.apache.hc.core5.http.message.BasicLineParser.parseProtocolVersion(BasicLineParser.java:110)
> at 
> org.apache.hc.core5.http.message.BasicLineParser.parseStatusLine(BasicLineParser.java:181)
> at 
> org.apache.hc.core5.http.impl.nio.DefaultHttpResponseParser.createMessage(DefaultHttpResponseParser.java:83)
> at 
> org.apache.hc.core5.http.impl.nio.DefaultHttpResponseParser.createMessage(DefaultHttpResponseParser.java:44)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractMessageParser.parseHeadLine(AbstractMessageParser.java:115)
> at 
> org.apache.hc.core5.http.impl.nio.AbstractMessageParser.parse(AbstractMessageParser.java:167)
> at 
> org.apache.hc.core5.ht

[jira] [Commented] (HTTPCLIENT-2220) file upload with MultipartEntityBuilder causes "socket write error"

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2220:
---

[~Sebastian Braun] What makes you think this has anything to do with HttpClient?

Oleg

> file upload with MultipartEntityBuilder causes "socket write error"
> ---
>
> Key: HTTPCLIENT-2220
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2220
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 4.5.3, 4.5.4, 4.5.5, 4.5.6, 4.5.7, 4.5.8, 4.5.9, 
> 4.5.10, 4.5.11, 4.5.12, 4.5.13
> Environment: server = Apache Server
>Reporter: Sebastian Braun
>Priority: Major
> Fix For: 4.5.13
>
>
> I have some trouble, uploading a file with the MultipartEntityBuilder using 
> the Apache HTTP client 4.5.13.
> It crashes with an {color:#de350b}"Software caused connection abort: socket 
> write error"{color} message.
> This kind of behavior did not occur in older versions, so I traced it back 
> back to the rather ancient version 4.5.2.
> 4.5.2  -> aborts with an socket write error
> 4.5.1  -> works fine
> It could be similar to this issue 
> https://issues.apache.org/jira/browse/HTTPCLIENT-1722.
> This issue is closed and a duplicate of another issue. Unfortunately there no 
> reference to the original issue, which might contain additional information.
> This is the source code:
> try (CloseableHttpClient client = HttpClients.createDefault()) {
>   File file = new File("readyForUpload.tar");
>   HttpPost postRequest = new HttpPost("https://...;);
>   // enable Expect: 100-continue, because the server
>   RequestConfig requestConfig = 
> RequestConfig.custom().setExpectContinueEnabled(true).build();
>  
>   HttpEntity entity = MultipartEntityBuilder.create()
>     .addBinaryBody("UPLOAD_FILENAME", file, 
> ContentType.APPLICATION_OCTET_STREAM, file.getName())
>     .addTextBody("SOME_TEXT", "lorem ipsum ...")
>     .build();
>  
>   postRequest.setConfig(requestConfig);
>   postRequest.setEntity(entity);
>  
>   HttpResponse response = client.execute(postRequest);
>   HttpEntity responseEntity = response.getEntity();
>  
>   System.out.println(response.getStatusLine());
>  
>   if (responseEntity != null) {
>     System.out.println(EntityUtils.toString(responseEntity));
>     EntityUtils.consume(responseEntity);
>   }
> }



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2215) support BRInputStreamFactory for handling br coded response

[Oleg Kalnichevski (Jira)]

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

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

Implemented in master (5.2.x).

Oleg

> support BRInputStreamFactory for handling br coded response
> ---
>
> Key: HTTPCLIENT-2215
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2215
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (async)
>Affects Versions: 5.2-alpha1
>Reporter: yinwoods
>Priority: Major
> Fix For: 5.2-alpha2
>
>
> gzip/deflate already implemented in httpclient5, should we support br ?
> I'd like to contribute a PR



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

-
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-beta2 based on RC1

[Oleg Kalnichevski]

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

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

no other votes

* binding votes
https://lists.apache.org/thread/h3zrz5wd1w4w0qy2qxb19cf0rpq4079n

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

Re: [VOTE] Release HttpCore 5.2-beta2 based on RC1

[Oleg Kalnichevski]

[x] +1 Release the packages as HttpCore 5.2-beta2.

On Sat, 2022-05-28 at 16:27 +0200, Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.2-beta2.
> The vote is open for the at least 72 hours, and only votes from
> HttpComponents PMC members are binding. The vote passes if at least
> three binding +1 votes are cast and there are more +1 than -1 votes.
> 
> Release notes:
>  
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2-beta2-RC1/RELEASE_NOTES-5.2.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1147/org/apache/httpcomponents/
> 
> Git Tag: 5.2-beta2-RC1
>  https://github.com/apache/httpcomponents-core/tree/5.2-beta2-RC1
> 
> Packages:
>  
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2-beta2-RC1
>  revision 54772
> 
> Hashes:
>  019b75b8a5efb4d3bf39007f0e1bcdc3fbfc20dde5181a7b8f8a27588dbb692dc03c
> 13b59f4d0a9f6aeb092ced9d710abb9cc9ae68f5fc03e9244a623d872ffb
> httpcomponents-core-5.2-beta2-src.zip httpcomponents-core-5.2-beta2-
> src.zip
>  de766702fae4f11b084bb7a5cd5b5899aee361a702f1f23237a066a1f6011beb54e2
> 0069bbc0fd9e88023b6033a449f65a705abcf5ddd2524854c10142a92830
> httpcomponents-core-5.2-beta2-bin.zip httpcomponents-core-5.2-beta2-
> bin.zip
>  ffb028874c8aa3f30249544c6370fe5dd82b849a28147b13e70caf2695a799a63fa9
> 44a609ce868d279495cf306c03a3ed6655d6d98e239c39e85e762ea6bf7a
> httpcomponents-core-5.2-beta2-bin.tar.gz httpcomponents-core-5.2-
> beta2-bin.tar.gz
>  3662a3b4564e4450279d43412f667d47f37c05f756621899bf4d783b430d95f219c9
> d27f91db6c6a2c36b1cc7bc665ec5cb72c585188c5e78f0f98d0ed88f2ad
> httpcomponents-core-5.2-beta2-src.tar.gz httpcomponents-core-5.2-
> beta2-src.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpcore/KEYS
> 
> ---
> ---
> Vote: HttpCore 5.2-beta2 release
> [ ] +1 Release the packages as HttpCore 5.2-beta2.
> [ ] -1 I am against releasing the packages (must include a reason).
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 


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

[VOTE] Release HttpCore 5.2-beta2 based on RC1

[Oleg Kalnichevski]

Please vote on releasing these packages as HttpCore 5.2-beta2.
The vote is open for the at least 72 hours, and only votes from
HttpComponents PMC members are binding. The vote passes if at least
three binding +1 votes are cast and there are more +1 than -1 votes.

Release notes:
 
https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2-beta2-RC1/RELEASE_NOTES-5.2.x.txt

Maven artefacts:
 
https://repository.apache.org/content/repositories/orgapachehttpcomponents-1147/org/apache/httpcomponents/

Git Tag: 5.2-beta2-RC1
 https://github.com/apache/httpcomponents-core/tree/5.2-beta2-RC1

Packages:
 https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2-beta2-RC1
 revision 54772

Hashes:
 
019b75b8a5efb4d3bf39007f0e1bcdc3fbfc20dde5181a7b8f8a27588dbb692dc03c13b59f4d0a9f6aeb092ced9d710abb9cc9ae68f5fc03e9244a623d872ffb
 httpcomponents-core-5.2-beta2-src.zip httpcomponents-core-5.2-beta2-src.zip
 
de766702fae4f11b084bb7a5cd5b5899aee361a702f1f23237a066a1f6011beb54e20069bbc0fd9e88023b6033a449f65a705abcf5ddd2524854c10142a92830
 httpcomponents-core-5.2-beta2-bin.zip httpcomponents-core-5.2-beta2-bin.zip
 
ffb028874c8aa3f30249544c6370fe5dd82b849a28147b13e70caf2695a799a63fa944a609ce868d279495cf306c03a3ed6655d6d98e239c39e85e762ea6bf7a
 httpcomponents-core-5.2-beta2-bin.tar.gz 
httpcomponents-core-5.2-beta2-bin.tar.gz
 
3662a3b4564e4450279d43412f667d47f37c05f756621899bf4d783b430d95f219c9d27f91db6c6a2c36b1cc7bc665ec5cb72c585188c5e78f0f98d0ed88f2ad
 httpcomponents-core-5.2-beta2-src.tar.gz 
httpcomponents-core-5.2-beta2-src.tar.gz

Keys:
 https://www.apache.org/dist/httpcomponents/httpcore/KEYS

--
Vote: HttpCore 5.2-beta2 release
[ ] +1 Release the packages as HttpCore 5.2-beta2.
[ ] -1 I am against releasing the packages (must include a reason).


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

[jira] [Resolved] (HTTPCLIENT-2218) Use Java 8 impl of Base64 instead of commons-codec

[Oleg Kalnichevski (Jira)]

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

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

Committed to master.

Oleg

> Use Java 8 impl of Base64 instead of commons-codec
> --
>
> Key: HTTPCLIENT-2218
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2218
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Johannes Graham
>Priority: Minor
> Fix For: 5.2-alpha2
>
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> If Java 8 is the new baseline for http-client, then switching to the 
> implementation available in the standard language would offer performance 
> improvements.
> I have an adaptor class to to this - I will open a PR with it.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

HttpCore 5.2-beta2 release notes

[Oleg Kalnichevski]

Folks

Please review and amend the HttpCore 5.2-beta2 release notes.

This would also be the right moment to run the latest code from the
master branch and see if there are any test failures, or propose
release process improvements.

https://github.com/apache/httpcomponents-core/blob/master/RELEASE_NOTES.txt

Oleg


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

Re: HttpCore and HttpClient releases soon?

[Oleg Kalnichevski]

On Wed, 2022-05-25 at 21:33 +0200, Michael Osipov wrote:
> Am 2022-05-24 um 09:18 schrieb Oleg Kalnichevski:
> > Folks
> > 
> > I would like to cut new releases of HttpCore 5.1, HttpCore 5.2 and
> > HttpClient 5.2. Will there be two more PMCs around to help me with
> > the
> > release?
> 
> I am here as well.
> 
> 

Awesome. I'll get started.

Oleg



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

HttpCore and HttpClient releases soon?

[Oleg Kalnichevski]

Folks

I would like to cut new releases of HttpCore 5.1, HttpCore 5.2 and
HttpClient 5.2. Will there be two more PMCs around to help me with the
release?

Oleg


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

[jira] [Commented] (HTTPCLIENT-2218) Use Java 8 impl of Base64 instead of commons-codec

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2218:
---

[~michael-o] We are not using for Base64 coding for anything performance 
critical. Better performance or not, it does not really matter much. What we 
should be able to do now is drop dependency on Commons Codec, which we solely 
use for Base64 coding.

Oleg

> Use Java 8 impl of Base64 instead of commons-codec
> --
>
> Key: HTTPCLIENT-2218
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2218
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Johannes Graham
>Priority: Minor
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> If Java 8 is the new baseline for http-client, then switching to the 
> implementation available in the standard language would offer performance 
> improvements.
> I have an adaptor class to to this - I will open a PR with it.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2216) ClosableHttpAsyncClient interface and testing

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2216:
---

> the issue I had was that `start()` and `close()` were not being defined on 
> the HttpAsyncClient interface alone.

[~dkrompet]  This was a conscious design decision. HTTP transport consumers 
should not be meddling with the life-cycle methods on the underlying client. 
The life-cycle management should be a responsibility of the client services or 
the application context. 
Does that make any sense?

Oleg

> ClosableHttpAsyncClient interface and testing
> -
>
> Key: HTTPCLIENT-2216
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2216
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async)
>Affects Versions: 5.0
>Reporter: Dillon Krompetz
>Priority: Minor
>
> TLDR: Please insert interface that contains functionality of 
> CloseableHttpAsyncClient so that this can be tested more easily.
> ===
> The current CloseableHttpAsyncClient implementation currently has a problem 
> in its interface and intended usage such that testing becomes more difficult 
> than it needs to be.
>  
> Class in question
> {code:java}
> public abstract class CloseableHttpAsyncClient implements HttpAsyncClient, 
> ModalCloseable {code}
>  
> Methods in question
> {code:java}
> public abstract void start(); {code}
> defined in CloseableHttpAsyncClient class
>  
> {code:java}
>  Future execute(
>   AsyncRequestProducer requestProducer,
>   AsyncResponseConsumer responseConsumer,
>   HandlerFactory pushHandlerFactory,
>   HttpContext context,
>   FutureCallback callback
> ); {code}
> defined in HttpAsyncClient interface
>  
> {code:java}
> void close(CloseMode closeMode); {code}
> defined in ModalCloseable interface
>  
> How is this an issue?
> When a developer goes to make use of the Http5 async client they may follow 
> the guides provided: 
> [https://hc.apache.org/httpcomponents-client-5.1.x/examples-async.html] and 
> see that they need access to the above three methods.
>  
> They may introduce an adapter around this interface to take thier business 
> logic and convert it into an Http request compatable with the client.
>  
> {code:java}
> class MyHttp5AsyncClient {
>   private CloseableHttpAsyncClient client;
>  
>   public MyHttp5AsyncClient(CloseableHttpAsyncClient httpAsyncClient) {
> this.client = httpAsyncClient;
>   }
>  
>   public start() {
> this.client.start();
>   }
>  
>   public stop() {
> this.client.close();
>   }
>  
>   public execute(MyRequest request) {
> AsyncRequestProducer requestProducer = toRequestProducer(request);
> Future result = client.execute(
>   requestProdcuer,
>   SimpleResponseConsumer.create(),
>   null,
>   null,
>   null
> );
> return result.get();
>   }
> } {code}
>  
> Note that in the CloseableHttpAsyncClient implementation that the execute 
> method is final:
> {code:java}
> public final  Future execute(
>   final HttpHost target,
>   final AsyncRequestProducer requestProducer,
>   final AsyncResponseConsumer responseConsumer,
>   final HandlerFactory pushHandlerFactory,
>   final HttpContext context,
>   final FutureCallback callback) {
> Args.notNull(requestProducer, "Request producer");
> Args.notNull(responseConsumer, "Response consumer");
> return doExecute(target, requestProducer, responseConsumer, 
> pushHandlerFactory, context, callback);
> } {code}
>  
> Testing
> Popular testing patterns include injecting the dependency into the class to 
> verify that methods were called with certain arguments or to mock the result 
> of calling a method to control the code flow in isolation. A very popular 
> Java mocking and verifying library might be Mockito where a developer may 
> write something like:
> {code:java}
> class MyHttp5AsyncClientTest {
>  
> @Mock
> private CloseableHttpAsyncClient client;
>  
> private MyHttp5AsyncClient toTest;
>  
> @BeforeEach
> public void setup() {
>   toTest = new MyHttp5AsyncClient(client);
> }
>  
> @Test
> public void execute_whenCalledWithSomeInput_thenWillDoTheThing() {
>   when(client.execute(
> any(AsyncRequestProducer.class),
> any(AsyncResponseConsumer.class),
> nullable(HandlerFactory.class),
> nullable(HttpContext.class),
> null

[jira] [Commented] (HTTPCLIENT-2216) ClosableHttpAsyncClient interface and testing

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2216:
---

[~dkrompet] I do not understand the issue. You should be mocking / injecting 
`HttpAsyncClient` not `CloseableHttpAsyncClient`. 
Client services should be using `HttpAsyncClient` not 
`CloseableHttpAsyncClient`. 

Oleg

> ClosableHttpAsyncClient interface and testing
> -
>
> Key: HTTPCLIENT-2216
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2216
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async)
>Affects Versions: 5.0
>Reporter: Dillon Krompetz
>Priority: Minor
>
> TLDR: Please insert interface that contains functionality of 
> CloseableHttpAsyncClient so that this can be tested more easily.
> ===
> The current CloseableHttpAsyncClient implementation currently has a problem 
> in its interface and intended usage such that testing becomes more difficult 
> than it needs to be.
>  
> Class in question
> {code:java}
> public abstract class CloseableHttpAsyncClient implements HttpAsyncClient, 
> ModalCloseable {code}
>  
> Methods in question
> {code:java}
> public abstract void start(); {code}
> defined in CloseableHttpAsyncClient class
>  
> {code:java}
>  Future execute(
>   AsyncRequestProducer requestProducer,
>   AsyncResponseConsumer responseConsumer,
>   HandlerFactory pushHandlerFactory,
>   HttpContext context,
>   FutureCallback callback
> ); {code}
> defined in HttpAsyncClient interface
>  
> {code:java}
> void close(CloseMode closeMode); {code}
> defined in ModalCloseable interface
>  
> How is this an issue?
> When a developer goes to make use of the Http5 async client they may follow 
> the guides provided: 
> [https://hc.apache.org/httpcomponents-client-5.1.x/examples-async.html] and 
> see that they need access to the above three methods.
>  
> They may introduce an adapter around this interface to take thier business 
> logic and convert it into an Http request compatable with the client.
>  
> {code:java}
> class MyHttp5AsyncClient {
>   private CloseableHttpAsyncClient client;
>  
>   public MyHttp5AsyncClient(CloseableHttpAsyncClient httpAsyncClient) {
> this.client = httpAsyncClient;
>   }
>  
>   public start() {
> this.client.start();
>   }
>  
>   public stop() {
> this.client.close();
>   }
>  
>   public execute(MyRequest request) {
> AsyncRequestProducer requestProducer = toRequestProducer(request);
> Future result = client.execute(
>   requestProdcuer,
>   SimpleResponseConsumer.create(),
>   null,
>   null,
>   null
> );
> return result.get();
>   }
> } {code}
>  
> Note that in the CloseableHttpAsyncClient implementation that the execute 
> method is final:
> {code:java}
> public final  Future execute(
>   final HttpHost target,
>   final AsyncRequestProducer requestProducer,
>   final AsyncResponseConsumer responseConsumer,
>   final HandlerFactory pushHandlerFactory,
>   final HttpContext context,
>   final FutureCallback callback) {
> Args.notNull(requestProducer, "Request producer");
> Args.notNull(responseConsumer, "Response consumer");
> return doExecute(target, requestProducer, responseConsumer, 
> pushHandlerFactory, context, callback);
> } {code}
>  
> Testing
> Popular testing patterns include injecting the dependency into the class to 
> verify that methods were called with certain arguments or to mock the result 
> of calling a method to control the code flow in isolation. A very popular 
> Java mocking and verifying library might be Mockito where a developer may 
> write something like:
> {code:java}
> class MyHttp5AsyncClientTest {
>  
> @Mock
> private CloseableHttpAsyncClient client;
>  
> private MyHttp5AsyncClient toTest;
>  
> @BeforeEach
> public void setup() {
>   toTest = new MyHttp5AsyncClient(client);
> }
>  
> @Test
> public void execute_whenCalledWithSomeInput_thenWillDoTheThing() {
>   when(client.execute(
> any(AsyncRequestProducer.class),
> any(AsyncResponseConsumer.class),
> nullable(HandlerFactory.class),
> nullable(HttpContext.class),
> nullable(FutureCallback.class)
>   )).thenReturn(
> CompletableFuture.completedFuture(null)
>   );
>  
>   var result = toTest.execute(null);
>   // ...
>   // some expectati

Re: Test failures on FreeBSD

[Oleg Kalnichevski]

On Wed, 2022-05-18 at 21:28 +0200, Michael Osipov wrote:
> Am 2022-05-18 um 17:47 schrieb Oleg Kalnichevski:
> > On Wed, 2022-05-18 at 16:26 +0200, Michael Osipov wrote:
> > > Am 2022-05-18 um 15:23 schrieb Oleg Kalnichevski:
> > > > Hi Michael
> > > > 
> > > > Could you please try the latest 1.8, 11, and 17 JDKs and see if
> > > > the
> > > > issue is consistently reproducible across all versions or is
> > > > specific
> > > > to some.
> > > 
> > > I see the failure consistently on all Java versions:
> > 
> > ...
> > 
> > 
> > > The server has plenty of resources and is mostly idle. I guess
> > > the
> > > thread per process limit is reached. I don't understand why it
> > > needs
> > > to
> > > scale that high for the test.
> > > 
> > > Do you need a thread dump at the time of the OOM?
> > > 
> > > M
> > > 
> > 
> > Could you please run this test with HttpCore master and let me know
> > if
> > it exhibits the same issue?
> 
> HttpCore5 from master works with 8, 11, 17 except for:

This is very bizarre. 

Could you please try out HttpClient master and 5.1.x branch and see if
they both exhibit the issue?

I relaxed the exception check in order to avoid TLS version mismatch
test failure on FreeBSD.

Oleg

> > [INFO] Running org.apache.hc.core5.testing.nio.TLSIntegrationTest
> > [ERROR] Tests run: 20, Failures: 1, Errors: 0, Skipped: 0, Time
> > elapsed: 8.225 s <<< FAILURE! - in
> > org.apache.hc.core5.testing.nio.TLSIntegrationTest
> > [ERROR]
> > org.apache.hc.core5.testing.nio.TLSIntegrationTest.testTLSVersionMi
> > smatch  Time elapsed: 0.317 s  <<< FAILURE!
> > org.opentest4j.AssertionFailedError: Unexpected type ==> expected:
> >  but was:
> > 
> > at
> > org.apache.hc.core5.testing.nio.TLSIntegrationTest.testTLSVersionMi
> > smatch(TLSIntegrationTest.java:361)
> > 

...


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

Re: Test failures on FreeBSD

[Oleg Kalnichevski]

On Wed, 2022-05-18 at 16:26 +0200, Michael Osipov wrote:
> Am 2022-05-18 um 15:23 schrieb Oleg Kalnichevski:
> > Hi Michael
> > 
> > Could you please try the latest 1.8, 11, and 17 JDKs and see if the
> > issue is consistently reproducible across all versions or is
> > specific
> > to some.
> 
> I see the failure consistently on all Java versions:

...


> The server has plenty of resources and is mostly idle. I guess the 
> thread per process limit is reached. I don't understand why it needs
> to 
> scale that high for the test.
> 
> Do you need a thread dump at the time of the OOM?
> 
> M
> 

Could you please run this test with HttpCore master and let me know if
it exhibits the same issue?

---
import org.apache.hc.core5.http.impl.bootstrap.HttpAsyncServer;
import org.apache.hc.core5.http.protocol.UriPatternMatcher;
import org.apache.hc.core5.http2.HttpVersionPolicy;
import org.apache.hc.core5.http2.impl.nio.bootstrap.H2ServerBootstrap;
import org.apache.hc.core5.io.CloseMode;
import org.apache.hc.core5.reactor.IOReactorConfig;
import org.apache.hc.core5.util.Timeout;
import org.junit.Rule;
import org.junit.jupiter.api.RepeatedTest;
import org.junit.jupiter.api.extension.ExtendWith;
import org.junit.jupiter.api.extension.Extensions;
import org.junit.jupiter.migrationsupport.rules.ExternalResourceSupport;
import org.junit.rules.ExternalResource;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

@Extensions({@ExtendWith({ExternalResourceSupport.class})})
public class H2ServerTest {

private final Logger log = LoggerFactory.getLogger(getClass());

private static final Timeout TIMEOUT = Timeout.ofSeconds(30);

private HttpAsyncServer server;

@Rule
public ExternalResource serverResource = new ExternalResource() {

@Override
protected void before() throws Throwable {
log.debug("Starting up test server");
server = H2ServerBootstrap.bootstrap()
.setLookupRegistry(new UriPatternMatcher<>())
.setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
.setIOReactorConfig(
IOReactorConfig.custom()
.setSoTimeout(TIMEOUT)
.build())

.setStreamListener(LoggingHttp1StreamListener.INSTANCE_SERVER)
.setStreamListener(LoggingH2StreamListener.INSTANCE)
.setIOSessionDecorator(LoggingIOSessionDecorator.INSTANCE)
.setExceptionCallback(LoggingExceptionCallback.INSTANCE)
.setIOSessionListener(LoggingIOSessionListener.INSTANCE)
.register("*", () -> new EchoHandler(2048))
.create();
}

@Override
protected void after() {
log.debug("Shutting down test server");
if (server != null) {
server.close(CloseMode.GRACEFUL);
}
}

};

@RepeatedTest(5000)
public void testSequentialRequests() throws Exception {
server.start();
}

}



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

Test failures on FreeBSD

[Oleg Kalnichevski]

Hi Michael

Could you please try the latest 1.8, 11, and 17 JDKs and see if the
issue is consistently reproducible across all versions or is specific
to some. 

Oleg

---
INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
5.085 s - in org.apache.hc.client5.testing.async.TestH2Reactive
[INFO] Running org.apache.hc.client5.testing.async.TestH2AsyncRedirect
Exception in thread "httpclient-main-1" java.lang.OutOfMemoryError:
unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:719)
at
java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.ja
va:957)
at
java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExe
cutor.java:1025)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja
va:1167)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j
ava:624)
at java.lang.Thread.run(Thread.java:750)
^C[WARNING] ForkStarter IOException: Stream Closed. See the dump file
/var/osipovmi/Projekte/httpcomponents-client/httpclient5-
testing/target/surefire-reports/2022-05-18T14-30-26_663-
jvmRun1.dumpstream


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

[jira] [Commented] (HTTPCLIENT-2215) support BRInputStreamFactory for handling br coded response

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2215:
---

[~yinwoods] I suppose you have given up too soon.  Apache Compress or br 
dependency could be made optional and the BR coding support could be activated 
only if the dependency has been explicitly added to the project model.  

We already have optional dependencies in the project such as Conscrypt.

Oleg

> support BRInputStreamFactory for handling br coded response
> ---
>
> Key: HTTPCLIENT-2215
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2215
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (async)
>Affects Versions: 5.2-alpha1
>Reporter: yinwoods
>Priority: Major
>
> gzip/deflate already implemented in httpclient5, should we support br ?
> I'd like to contribute a PR



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2215) support BRInputStreamFactory for handling br coded response

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2215:
---

[~yinwoods] Absolutely! This would be a very welcome contribution!

Oleg

> support BRInputStreamFactory for handling br coded response
> ---
>
> Key: HTTPCLIENT-2215
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2215
> Project: HttpComponents HttpClient
>  Issue Type: New Feature
>  Components: HttpClient (async)
>Affects Versions: 5.2-alpha1
>Reporter: yinwoods
>Priority: Major
>
> gzip/deflate already implemented in httpclient5, should we support br ?
> I'd like to contribute a PR



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2214) MemcachedHttpAsyncCacheStorage should use MemcachedClientIF interface

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2214.
---
Resolution: Fixed

[~dkrompet] Please see HTTPCLIENT-2204 for detailed explanation why this is not 
a bug.

Oleg

> MemcachedHttpAsyncCacheStorage should use MemcachedClientIF interface
> -
>
> Key: HTTPCLIENT-2214
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2214
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpCache
>Affects Versions: 5.0, 5.1, 5.1.2, 5.1.3
>Reporter: Dillon Krompetz
>Priority: Minor
>
> Similar to https://issues.apache.org/jira/browse/HTTPCLIENT-2202
> There also seems to have been a similar regression from 4.x to 5.x in terms 
> of using hard implementations of MemcachedClient object over interface 
> MemcachedClientIF.
> Changing to use MemcachedClientIF would again here be backwards compatible 
> due to Memcached.
> {code:java}
> public class MemcachedHttpAsyncCacheStorage extends 
> AbstractBinaryAsyncCacheStorage> {
> private final MemcachedClient client;
> private final KeyHashingScheme keyHashingScheme;
> public MemcachedHttpAsyncCacheStorage(final InetSocketAddress address) throws 
> IOException { 
>   this(new MemcachedClient(address)); 
> } 
> ...{code}



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2213:
---

> That is not what I'm seeing: I'm seeing that releaseConnection is called when 
> I'm calling `EntityUtils.consume(res.getEntity())`.

[~Paul Bakker] There might be entire the entire message body stuck in the 
session buffer, but the message body is considered fully received only after th 
receipt of the end of stream (-1). This is exactly what `EntityUtils#consume`. 
it just reads the content until the end of stream. You need to improve your 
application code to continue reading from the content stream until the end of 
stream.

Oleg

> Mechanism to not use pooled connections beyond the keep-alive period is flawed
> --
>
> Key: HTTPCLIENT-2213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.13, 5.1.4
>Reporter: Paul Bakker
>Priority: Minor
>
> When making a request using the HTTPClient to an endpoint that returns a 
> Keep-Alive header in the response with a timeout value of say 5 seconds, then 
> in org.apache.http.impl.execchain.MainClientExec.execute, directly after the 
> request was made the timeout value (5 seconds) from the response is stored on 
> the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).
> This value stored on the ConnectionHolder is used once the connection is 
> released back to the connection pool, in 
> PoolingHttpClientConnectionManager.releaseConnection(...), by making a call 
> to PoolEntry.updateExpiry(...).
> The .updateExpiry() method then updates its 'expiry' field with the timestamp 
> when the connection is to be considered not valid anymore (which gets checked 
> when leasing a connection from the pool).
> However, the logic in .updateExpiry(..) to calculate the new `expiry` 
> timestamp basically does `System.currentTimeMillis() + duration` (with 
> duration being 5 seconds in this example). This is problematic, because the 5 
> seconds Keep-Alive interval is relative to the moment to receiving the 
> response in the aforementioned .execute(...) method. The calculation in 
> .updateExpiry(...) however calculates it reletive to the moment that 
> .updateExpiry(...) is called, which, depending on the implementation, could 
> be quite some time later, which could result 
> inPoolingHttpClientConnectionManager. leaseConnection(...) returning a 
> connection from the pool, which isn't alive anymore.
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2213.
---
Resolution: Invalid

> Mechanism to not use pooled connections beyond the keep-alive period is flawed
> --
>
> Key: HTTPCLIENT-2213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.13, 5.1.4
>Reporter: Paul Bakker
>Priority: Minor
>
> When making a request using the HTTPClient to an endpoint that returns a 
> Keep-Alive header in the response with a timeout value of say 5 seconds, then 
> in org.apache.http.impl.execchain.MainClientExec.execute, directly after the 
> request was made the timeout value (5 seconds) from the response is stored on 
> the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).
> This value stored on the ConnectionHolder is used once the connection is 
> released back to the connection pool, in 
> PoolingHttpClientConnectionManager.releaseConnection(...), by making a call 
> to PoolEntry.updateExpiry(...).
> The .updateExpiry() method then updates its 'expiry' field with the timestamp 
> when the connection is to be considered not valid anymore (which gets checked 
> when leasing a connection from the pool).
> However, the logic in .updateExpiry(..) to calculate the new `expiry` 
> timestamp basically does `System.currentTimeMillis() + duration` (with 
> duration being 5 seconds in this example). This is problematic, because the 5 
> seconds Keep-Alive interval is relative to the moment to receiving the 
> response in the aforementioned .execute(...) method. The calculation in 
> .updateExpiry(...) however calculates it reletive to the moment that 
> .updateExpiry(...) is called, which, depending on the implementation, could 
> be quite some time later, which could result 
> inPoolingHttpClientConnectionManager. leaseConnection(...) returning a 
> connection from the pool, which isn't alive anymore.
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2213:
---

> So I guess a better approach would be to calculate the expiry timestamp at 
> the moment when the entire response from the server has been received, but no 
> idea if thats is a moment that is/can be explicitly known within the 
> HTTPClient library. Is there?

[~Paul Bakker] HttpClient triggers the connection release the same very moment 
it has received the entire response body. Basically the algorithm you are 
describing is pretty much how HttpClient works now.

Oleg

> Mechanism to not use pooled connections beyond the keep-alive period is flawed
> --
>
> Key: HTTPCLIENT-2213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.13, 5.1.4
>Reporter: Paul Bakker
>Priority: Minor
>
> When making a request using the HTTPClient to an endpoint that returns a 
> Keep-Alive header in the response with a timeout value of say 5 seconds, then 
> in org.apache.http.impl.execchain.MainClientExec.execute, directly after the 
> request was made the timeout value (5 seconds) from the response is stored on 
> the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).
> This value stored on the ConnectionHolder is used once the connection is 
> released back to the connection pool, in 
> PoolingHttpClientConnectionManager.releaseConnection(...), by making a call 
> to PoolEntry.updateExpiry(...).
> The .updateExpiry() method then updates its 'expiry' field with the timestamp 
> when the connection is to be considered not valid anymore (which gets checked 
> when leasing a connection from the pool).
> However, the logic in .updateExpiry(..) to calculate the new `expiry` 
> timestamp basically does `System.currentTimeMillis() + duration` (with 
> duration being 5 seconds in this example). This is problematic, because the 5 
> seconds Keep-Alive interval is relative to the moment to receiving the 
> response in the aforementioned .execute(...) method. The calculation in 
> .updateExpiry(...) however calculates it reletive to the moment that 
> .updateExpiry(...) is called, which, depending on the implementation, could 
> be quite some time later, which could result 
> inPoolingHttpClientConnectionManager. leaseConnection(...) returning a 
> connection from the pool, which isn't alive anymore.
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2213:
---

> it should instead record the expiry time, by doing the calculation 
> (System.currentTimeMillis() + duration) right there, directly after the 
> response was received

[~Paul Bakker] What makes you think this is the correct / standard  behavior? 
What makes you think this value defines the period of time starting from the 
receipt of the HTTP response _head_ and not the _entire_ HTTP response message?

Oleg

> Mechanism to not use pooled connections beyond the keep-alive period is flawed
> --
>
> Key: HTTPCLIENT-2213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.13, 5.1.4
>Reporter: Paul Bakker
>Priority: Minor
>
> When making a request using the HTTPClient to an endpoint that returns a 
> Keep-Alive header in the response with a timeout value of say 5 seconds, then 
> in org.apache.http.impl.execchain.MainClientExec.execute, directly after the 
> request was made the timeout value (5 seconds) from the response is stored on 
> the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).
> This value stored on the ConnectionHolder is used once the connection is 
> released back to the connection pool, in 
> PoolingHttpClientConnectionManager.releaseConnection(...), by making a call 
> to PoolEntry.updateExpiry(...).
> The .updateExpiry() method then updates its 'expiry' field with the timestamp 
> when the connection is to be considered not valid anymore (which gets checked 
> when leasing a connection from the pool).
> However, the logic in .updateExpiry(..) to calculate the new `expiry` 
> timestamp basically does `System.currentTimeMillis() + duration` (with 
> duration being 5 seconds in this example). This is problematic, because the 5 
> seconds Keep-Alive interval is relative to the moment to receiving the 
> response in the aforementioned .execute(...) method. The calculation in 
> .updateExpiry(...) however calculates it reletive to the moment that 
> .updateExpiry(...) is called, which, depending on the implementation, could 
> be quite some time later, which could result 
> inPoolingHttpClientConnectionManager. leaseConnection(...) returning a 
> connection from the pool, which isn't alive anymore.
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2213:
---

[~Paul Bakker] Connection expiry time calculation is never precise and cannot 
be precise when using relative values. It is basically on a per best effort 
basis. What is it exactly you would like us to do here?

Oleg

> Mechanism to not use pooled connections beyond the keep-alive period is flawed
> --
>
> Key: HTTPCLIENT-2213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.13, 5.1.4
>Reporter: Paul Bakker
>Priority: Minor
>
> When making a request using the HTTPClient to an endpoint that returns a 
> Keep-Alive header in the response with a timeout value of say 5 seconds, then 
> in org.apache.http.impl.execchain.MainClientExec.execute, directly after the 
> request was made the timeout value (5 seconds) from the response is stored on 
> the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).
> This value stored on the ConnectionHolder is used once the connection is 
> released back to the connection pool, in 
> PoolingHttpClientConnectionManager.releaseConnection(...), by making a call 
> to PoolEntry.updateExpiry(...).
> The .updateExpiry() method then updates its 'expiry' field with the timestamp 
> when the connection is to be considered not valid anymore (which gets checked 
> when leasing a connection from the pool).
> However, the logic in .updateExpiry(..) to calculate the new `expiry` 
> timestamp basically does `System.currentTimeMillis() + duration` (with 
> duration being 5 seconds in this example). This is problematic, because the 5 
> seconds Keep-Alive interval is relative to the moment to receiving the 
> response in the aforementioned .execute(...) method. The calculation in 
> .updateExpiry(...) however calculates it reletive to the moment that 
> .updateExpiry(...) is called, which, depending on the implementation, could 
> be quite some time later, which could result 
> inPoolingHttpClientConnectionManager. leaseConnection(...) returning a 
> connection from the pool, which isn't alive anymore.
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Updated] (HTTPCLIENT-2213) Mechanism to not use pooled connections beyond the keep-alive period is flawed

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski updated HTTPCLIENT-2213:
--
Issue Type: Improvement  (was: Bug)
  Priority: Minor  (was: Major)

> Mechanism to not use pooled connections beyond the keep-alive period is flawed
> --
>
> Key: HTTPCLIENT-2213
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2213
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (async), HttpClient (classic)
>Affects Versions: 4.5.13, 5.1.4
>Reporter: Paul Bakker
>Priority: Minor
>
> When making a request using the HTTPClient to an endpoint that returns a 
> Keep-Alive header in the response with a timeout value of say 5 seconds, then 
> in org.apache.http.impl.execchain.MainClientExec.execute, directly after the 
> request was made the timeout value (5 seconds) from the response is stored on 
> the ConnectionHolder by making a call to ConnectionHolder.setValidFor(...).
> This value stored on the ConnectionHolder is used once the connection is 
> released back to the connection pool, in 
> PoolingHttpClientConnectionManager.releaseConnection(...), by making a call 
> to PoolEntry.updateExpiry(...).
> The .updateExpiry() method then updates its 'expiry' field with the timestamp 
> when the connection is to be considered not valid anymore (which gets checked 
> when leasing a connection from the pool).
> However, the logic in .updateExpiry(..) to calculate the new `expiry` 
> timestamp basically does `System.currentTimeMillis() + duration` (with 
> duration being 5 seconds in this example). This is problematic, because the 5 
> seconds Keep-Alive interval is relative to the moment to receiving the 
> response in the aforementioned .execute(...) method. The calculation in 
> .updateExpiry(...) however calculates it reletive to the moment that 
> .updateExpiry(...) is called, which, depending on the implementation, could 
> be quite some time later, which could result 
> inPoolingHttpClientConnectionManager. leaseConnection(...) returning a 
> connection from the pool, which isn't alive anymore.
>   



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCLIENT-2212) AsyncClientEndpoint is not released upon lease failure

[Oleg Kalnichevski (Jira)]

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

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

> AsyncClientEndpoint is not released upon lease failure
> --
>
> Key: HTTPCLIENT-2212
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2212
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3, 5.2-alpha1
>Reporter: Lubos Husivarga
>Priority: Major
> Fix For: 5.1.4, 5.2-alpha2
>
>
> When I use AsyncHttpClient and try to lease an endpoint to host 
> "https://localhost;, I receive javax.net.ssl.SSLHandshakeException exception 
> via callback's failed method. That's ok, because my localhost certificate is 
> not signed by authority.
> The strange thing is that the endpoint is allocated from 
> PoolingAsyncClientConnectionManager, but not released after the connection 
> failure during the endpoint lease operation.
> There is no way to release the endpoint from callback failed method, because 
> there is no reference to it.
> Failing the lease multiple times consumes all available connections from 
> connection manager pool and any further lease operation remains in pending 
> state preventing any other connections to the host.
> example:
>  
> {code:java}
> httpManager = PoolingAsyncClientConnectionManagerBuilder.create()
>         .setDefaultConnectionConfig(ConnectionConfig.custom()
>                 .setTimeToLive(TimeValue.NEG_ONE_MILLISECOND)    //TTL is 
> maximum time one connection can be used,
>                         //then it is closed and new one is opened. Therefore 
> -1 disables TTL and same connection lasts until
>                         //it is actively used. Then closed by 
> IdleConnectionEvictor thread.
>                 .build())
>         .setDefaultTlsConfig(TlsConfig.custom()
>                 .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
>                 .build())
>         .build();
> httpClient = HttpAsyncClients.createMinimal(
>         H2Config.DEFAULT,
>         Http1Config.DEFAULT,
>         IOReactorConfig.DEFAULT,
>         httpManager);
> httpClient.start();
>  
> HttpHost host = new HttpHost("https", "localhost", 443);
> httpClient.lease(host, new FutureCallback() {
>                             @Override
>                             public void failed(Exception ex) {
>                             }
>                             
>                             @Override
>                             public void completed(AsyncClientEndpoint result) 
> {
>                             }
>                             
>                             @Override
>                             public void cancelled() {
>                             }
>                         });
>  
> Set routes = httpManager.getRoutes();
>         List stats = new ArrayList(routes.size());
>         
>         for(HttpRoute route : routes){
>             PoolStats s = httpManager.getStats(route);
>             System.out.println(route.getTargetHost().getHostName());
>             System.out.println(s.getAvailable());
>             System.out.println(s.getLeased());
>             System.out.println(s.getMax());
>             System.out.println(s.getPending());
>         }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2212) AsyncClientEndpoint is not released upon lease failure

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2212:
---

[~lhusivarga]  Please review / test the proposed fix:

[https://github.com/apache/httpcomponents-client/commit/830adcd254e6b7be305c112ca004720c0d14d887]

Oleg

> AsyncClientEndpoint is not released upon lease failure
> --
>
> Key: HTTPCLIENT-2212
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2212
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.1.3, 5.2-alpha1
>Reporter: Lubos Husivarga
>Priority: Major
>
> When I use AsyncHttpClient and try to lease an endpoint to host 
> "https://localhost;, I receive javax.net.ssl.SSLHandshakeException exception 
> via callback's failed method. That's ok, because my localhost certificate is 
> not signed by authority.
> The strange thing is that the endpoint is allocated from 
> PoolingAsyncClientConnectionManager, but not released after the connection 
> failure during the endpoint lease operation.
> There is no way to release the endpoint from callback failed method, because 
> there is no reference to it.
> Failing the lease multiple times consumes all available connections from 
> connection manager pool and any further lease operation remains in pending 
> state preventing any other connections to the host.
> example:
>  
> {code:java}
> httpManager = PoolingAsyncClientConnectionManagerBuilder.create()
>         .setDefaultConnectionConfig(ConnectionConfig.custom()
>                 .setTimeToLive(TimeValue.NEG_ONE_MILLISECOND)    //TTL is 
> maximum time one connection can be used,
>                         //then it is closed and new one is opened. Therefore 
> -1 disables TTL and same connection lasts until
>                         //it is actively used. Then closed by 
> IdleConnectionEvictor thread.
>                 .build())
>         .setDefaultTlsConfig(TlsConfig.custom()
>                 .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
>                 .build())
>         .build();
> httpClient = HttpAsyncClients.createMinimal(
>         H2Config.DEFAULT,
>         Http1Config.DEFAULT,
>         IOReactorConfig.DEFAULT,
>         httpManager);
> httpClient.start();
>  
> HttpHost host = new HttpHost("https", "localhost", 443);
> httpClient.lease(host, new FutureCallback() {
>                             @Override
>                             public void failed(Exception ex) {
>                             }
>                             
>                             @Override
>                             public void completed(AsyncClientEndpoint result) 
> {
>                             }
>                             
>                             @Override
>                             public void cancelled() {
>                             }
>                         });
>  
> Set routes = httpManager.getRoutes();
>         List stats = new ArrayList(routes.size());
>         
>         for(HttpRoute route : routes){
>             PoolStats s = httpManager.getStats(route);
>             System.out.println(route.getTargetHost().getHostName());
>             System.out.println(s.getAvailable());
>             System.out.println(s.getLeased());
>             System.out.println(s.getMax());
>             System.out.println(s.getPending());
>         }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Moved] (HTTPCLIENT-2212) AsyncClientEndpoint is not released upon lease failure

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski moved HTTPCORE-712 to HTTPCLIENT-2212:


  Component/s: HttpClient (async)
   (was: HttpCore NIO)
  Key: HTTPCLIENT-2212  (was: HTTPCORE-712)
Affects Version/s: 5.2-alpha1
   5.1.3
   (was: 5.2-alpha1)
 Workflow: Default workflow, editable Closed status  (was: classic 
default workflow)
  Project: HttpComponents HttpClient  (was: HttpComponents HttpCore)

> AsyncClientEndpoint is not released upon lease failure
> --
>
> Key: HTTPCLIENT-2212
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2212
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2-alpha1, 5.1.3
>Reporter: Lubos Husivarga
>Priority: Major
>
> When I use AsyncHttpClient and try to lease an endpoint to host 
> "https://localhost;, I receive javax.net.ssl.SSLHandshakeException exception 
> via callback's failed method. That's ok, because my localhost certificate is 
> not signed by authority.
> The strange thing is that the endpoint is allocated from 
> PoolingAsyncClientConnectionManager, but not released after the connection 
> failure during the endpoint lease operation.
> There is no way to release the endpoint from callback failed method, because 
> there is no reference to it.
> Failing the lease multiple times consumes all available connections from 
> connection manager pool and any further lease operation remains in pending 
> state preventing any other connections to the host.
> example:
>  
> {code:java}
> httpManager = PoolingAsyncClientConnectionManagerBuilder.create()
>         .setDefaultConnectionConfig(ConnectionConfig.custom()
>                 .setTimeToLive(TimeValue.NEG_ONE_MILLISECOND)    //TTL is 
> maximum time one connection can be used,
>                         //then it is closed and new one is opened. Therefore 
> -1 disables TTL and same connection lasts until
>                         //it is actively used. Then closed by 
> IdleConnectionEvictor thread.
>                 .build())
>         .setDefaultTlsConfig(TlsConfig.custom()
>                 .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
>                 .build())
>         .build();
> httpClient = HttpAsyncClients.createMinimal(
>         H2Config.DEFAULT,
>         Http1Config.DEFAULT,
>         IOReactorConfig.DEFAULT,
>         httpManager);
> httpClient.start();
>  
> HttpHost host = new HttpHost("https", "localhost", 443);
> httpClient.lease(host, new FutureCallback() {
>                             @Override
>                             public void failed(Exception ex) {
>                             }
>                             
>                             @Override
>                             public void completed(AsyncClientEndpoint result) 
> {
>                             }
>                             
>                             @Override
>                             public void cancelled() {
>                             }
>                         });
>  
> Set routes = httpManager.getRoutes();
>         List stats = new ArrayList(routes.size());
>         
>         for(HttpRoute route : routes){
>             PoolStats s = httpManager.getStats(route);
>             System.out.println(route.getTargetHost().getHostName());
>             System.out.println(s.getAvailable());
>             System.out.println(s.getLeased());
>             System.out.println(s.getMax());
>             System.out.println(s.getPending());
>         }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-712) AsyncClientEndpoint is not released upon lease failure

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-712:


[~lhusivarga] The defect is actually in HttpClient, not HttpCore.

Oleg

> AsyncClientEndpoint is not released upon lease failure
> --
>
> Key: HTTPCORE-712
> URL: https://issues.apache.org/jira/browse/HTTPCORE-712
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 5.2-alpha1
>Reporter: Lubos Husivarga
>Priority: Major
>
> When I use AsyncHttpClient and try to lease an endpoint to host 
> "https://localhost;, I receive javax.net.ssl.SSLHandshakeException exception 
> via callback's failed method. That's ok, because my localhost certificate is 
> not signed by authority.
> The strange thing is that the endpoint is allocated from 
> PoolingAsyncClientConnectionManager, but not released after the connection 
> failure during the endpoint lease operation.
> There is no way to release the endpoint from callback failed method, because 
> there is no reference to it.
> Failing the lease multiple times consumes all available connections from 
> connection manager pool and any further lease operation remains in pending 
> state preventing any other connections to the host.
> example:
>  
> {code:java}
> httpManager = PoolingAsyncClientConnectionManagerBuilder.create()
>         .setDefaultConnectionConfig(ConnectionConfig.custom()
>                 .setTimeToLive(TimeValue.NEG_ONE_MILLISECOND)    //TTL is 
> maximum time one connection can be used,
>                         //then it is closed and new one is opened. Therefore 
> -1 disables TTL and same connection lasts until
>                         //it is actively used. Then closed by 
> IdleConnectionEvictor thread.
>                 .build())
>         .setDefaultTlsConfig(TlsConfig.custom()
>                 .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
>                 .build())
>         .build();
> httpClient = HttpAsyncClients.createMinimal(
>         H2Config.DEFAULT,
>         Http1Config.DEFAULT,
>         IOReactorConfig.DEFAULT,
>         httpManager);
> httpClient.start();
>  
> HttpHost host = new HttpHost("https", "localhost", 443);
> httpClient.lease(host, new FutureCallback() {
>                             @Override
>                             public void failed(Exception ex) {
>                             }
>                             
>                             @Override
>                             public void completed(AsyncClientEndpoint result) 
> {
>                             }
>                             
>                             @Override
>                             public void cancelled() {
>                             }
>                         });
>  
> Set routes = httpManager.getRoutes();
>         List stats = new ArrayList(routes.size());
>         
>         for(HttpRoute route : routes){
>             PoolStats s = httpManager.getStats(route);
>             System.out.println(route.getTargetHost().getHostName());
>             System.out.println(s.getAvailable());
>             System.out.println(s.getLeased());
>             System.out.println(s.getMax());
>             System.out.println(s.getPending());
>         }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Resolved] (HTTPCORE-713) Optimize InetAddressUtils#isIPv6*Address checks

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-713.

Fix Version/s: 5.1.4
   5.2-beta2
   Resolution: Fixed

> Optimize InetAddressUtils#isIPv6*Address checks
> ---
>
> Key: HTTPCORE-713
> URL: https://issues.apache.org/jira/browse/HTTPCORE-713
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Reporter: David Schlosnagle
>Priority: Major
> Fix For: 5.1.4, 5.2-beta2
>
> Attachments: 166573589-2c814d53-9639-4b14-82d0-9238f285be0b.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> See https://github.com/apache/httpcomponents-core/pull/347
> Check input colon count before performing IPv6 regex validation.
> {{org.apache.hc.core5.net.InetAddressUtils.isIPv6Address}} is used when 
> constructing the {{host}} header for requests, and currently allocates a 
> regex matcher when checking if the provided address is an IPv6 address. This 
> is generates excess garbage and CPU cycles, especially in environments with 
> mostly IPv4 addresses. By checking the colon count first, we see a 50x 
> improvement checking {{InetAddressUtils.isIPv6Address}} for an IPv4 address.
> The specific call backtrace seen looks like:
> {code:java}
> void java.util.regex.Matcher.(Pattern, CharSequence)
>    Matcher java.util.regex.Pattern.matcher(CharSequence)
>    boolean 
> org.apache.hc.core5.net.InetAddressUtils.isIPv6HexCompressedAddress(String)
>       boolean org.apache.hc.core5.net.InetAddressUtils.isIPv6Address(String)
>       void org.apache.hc.core5.net.Host.format(StringBuilder, NamedEndpoint)
>       void org.apache.hc.core5.net.URIAuthority.format(StringBuilder, 
> URIAuthority)
>          String org.apache.hc.core5.net.URIAuthority.format(URIAuthority)
>          String org.apache.hc.core5.net.URIAuthority.toString()
>          String java.util.Objects.toString(Object, String)
>          void org.apache.hc.core5.http.message.BasicHeader.(String, 
> Object, boolean)
>          void org.apache.hc.core5.http.message.BasicHeader.(String, 
> Object)
>          void 
> org.apache.hc.core5.http.message.BasicHttpRequest.addHeader(String, Object)
>          void 
> org.apache.hc.core5.http.protocol.RequestTargetHost.process(HttpRequest, 
> EntityDetails, HttpContext)
>          void 
> org.apache.hc.core5.http.protocol.DefaultHttpProcessor.process(HttpRequest, 
> EntityDetails, HttpContext)
>          ClassicHttpResponse 
> org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ClassicHttpRequest,
>  ExecChain$Scope, ExecChain)
>          ClassicHttpResponse 
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ClassicHttpRequest,
>  ExecChain$Scope)
>          ClassicHttpResponse 
> org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ClassicHttpRequest,
>  ExecChain$Scope)
>          ClassicHttpResponse 
> org.apache.hc.client5.http.impl.classic.RedirectExec.execute(ClassicHttpRequest,
>  ExecChain$Scope, ExecChain)
>          ClassicHttpResponse 
> org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ClassicHttpRequest,
>  ExecChain$Scope)
>          CloseableHttpResponse 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(HttpHost,
>  ClassicHttpRequest, HttpContext)
>          CloseableHttpResponse 
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(ClassicHttpRequest,
>  HttpContext)
>          CloseableHttpResponse 
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(ClassicHttpRequest)
> {code}
> From JFR profile: 
> !166573589-2c814d53-9639-4b14-82d0-9238f285be0b.png! 



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-712) AsyncClientEndpoint is not released upon lease failure

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-712:


[~lhusivarga] I will look into it shortly.

Oleg

> AsyncClientEndpoint is not released upon lease failure
> --
>
> Key: HTTPCORE-712
> URL: https://issues.apache.org/jira/browse/HTTPCORE-712
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 5.2-alpha1
>Reporter: Lubos Husivarga
>Priority: Major
>
> When I use AsyncHttpClient and try to lease an endpoint to host 
> "https://localhost;, I receive javax.net.ssl.SSLHandshakeException exception 
> via callback's failed method. That's ok, because my localhost certificate is 
> not signed by authority.
> The strange thing is that the endpoint is allocated from 
> PoolingAsyncClientConnectionManager, but not released after the connection 
> failure during the endpoint lease operation.
> There is no way to release the endpoint from callback failed method, because 
> there is no reference to it.
> Failing the lease multiple times consumes all available connections from 
> connection manager pool and any further lease operation remains in pending 
> state preventing any other connections to the host.
> example:
>  
> {code:java}
> httpManager = PoolingAsyncClientConnectionManagerBuilder.create()
>         .setDefaultConnectionConfig(ConnectionConfig.custom()
>                 .setTimeToLive(TimeValue.NEG_ONE_MILLISECOND)    //TTL is 
> maximum time one connection can be used,
>                         //then it is closed and new one is opened. Therefore 
> -1 disables TTL and same connection lasts until
>                         //it is actively used. Then closed by 
> IdleConnectionEvictor thread.
>                 .build())
>         .setDefaultTlsConfig(TlsConfig.custom()
>                 .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
>                 .build())
>         .build();
> httpClient = HttpAsyncClients.createMinimal(
>         H2Config.DEFAULT,
>         Http1Config.DEFAULT,
>         IOReactorConfig.DEFAULT,
>         httpManager);
> httpClient.start();
>  
> HttpHost host = new HttpHost("https", "localhost", 443);
> httpClient.lease(host, new FutureCallback() {
>                             @Override
>                             public void failed(Exception ex) {
>                             }
>                             
>                             @Override
>                             public void completed(AsyncClientEndpoint result) 
> {
>                             }
>                             
>                             @Override
>                             public void cancelled() {
>                             }
>                         });
>  
> Set routes = httpManager.getRoutes();
>         List stats = new ArrayList(routes.size());
>         
>         for(HttpRoute route : routes){
>             PoolStats s = httpManager.getStats(route);
>             System.out.println(route.getTargetHost().getHostName());
>             System.out.println(s.getAvailable());
>             System.out.println(s.getLeased());
>             System.out.println(s.getMax());
>             System.out.println(s.getPending());
>         }
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCORE-711) Integration of httpcomponents-core into OSS-Fuzz

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-711:


[~onionpsy]  Ideally all communication should happen on 
[dev@hc.apache.org|mailto:dev@hc.apache.org], not directly with individual 
project committers. This is a general ASF policy.

Oleg

> Integration of httpcomponents-core into OSS-Fuzz
> 
>
> Key: HTTPCORE-711
> URL: https://issues.apache.org/jira/browse/HTTPCORE-711
> Project: HttpComponents HttpCore
>  Issue Type: Test
>  Components: HttpCore
>Reporter: Patrice
>Priority: Minor
>
> Hi all,
> I have prepared the initial integration 
> [https://github.com/CodeIntelligenceTesting/oss-fuzz/commit/88316189c9c57b7846e1bc78cf23b70e6087093e]
>  of httpcomponents-core into [google 
> oss-fuzz|https://github.com/google/oss-fuzz]. This will enable continuous 
> fuzzing of this project, which will be conducted by Google. Bugs that will be 
> found by fuzzing will be reported to you. After the initial integration of 
> this project into oss-fuzz, I will continue to add additional fuzz tests to 
> improve the code coverage over time.
> The integration requires a primary contact, someone to deal with the bug 
> reports submitted by oss-fuzz. The email address needs to belong to an 
> established project committer and be associated with a Google account as per 
> [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/].
>  When a bug is found, you will receive an email that will provide you with 
> access to ClusterFuzz, crash reports, and fuzzer statistics. More than 1 
> person can be included. Please let me know who I should include, if anyone.
> [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] is used for 
> fuzzing Java applications. Jazzer is a coverage-guided, in-process fuzzer for 
> the JVM platform developed by Code Intelligence. It is based on libFuzzer and 
> brings many of its instrumentation-powered mutation features to the JVM. 
> Jazzer has already found several bugs in JVM applications: [Jazzer 
> Findings|https://github.com/CodeIntelligenceTesting/jazzer#findings]
> Please let me know if you have any questions regarding fuzzing or the 
> oss-fuzz integration.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

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

[jira] [Commented] (HTTPCLIENT-2211) content-length header should not be sent when chunked encoding specified

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2211:
---

>  Also notice content-length does not show up in headers if you have 
> org.apache.hc.client5.http.headers turned up to Debug

[~patrickjamesbarry] The content-length does not show up because it is simply 
not there. HttpClient does not generate it and does not sent it to the opposite 
endpoint. 

GET (as well as DELETE) requests with an enclosed entity are _monumentally 
stupid_ and a lot of servers and proxies have trouble dealing with them. Please 
review your server side code.

Oleg

> content-length header should not be sent when chunked encoding specified
> 
>
> Key: HTTPCLIENT-2211
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2211
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 5.1.3
>Reporter: Patrick Barry
>Priority: Major
>
> According to HTTP 1.1 spec, content-length header should never be sent with 
> Transfer-Encoding: chunked on request.  However, when you send a request 
> using a non-body Method like GET or DELETE using this async client, it is 
> adding content-length:0 to the request.  This header should not be sent 
> according to RFC.
> Because it is sent, it causes the server that is responding to either reject 
> the request with a 400 or go down other paths. For example, Tomcat 9 chose to 
> accept the request but will close the connection, even if 
> Connection:Keep-Alive is requested on request.  This has major performance 
> drawbacks, and is only one way a server chose to handle this.
>  
> As per RFC 7230:
> 
> A sender MUST NOT send a Content-Length header field in any message that 
> contains a Transfer-Encoding header field.
> 



--
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] [Resolved] (HTTPCLIENT-2211) content-length header should not be sent when chunked encoding specified

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCLIENT-2211.
---
Resolution: Invalid

> content-length header should not be sent when chunked encoding specified
> 
>
> Key: HTTPCLIENT-2211
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2211
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 5.1.3
>Reporter: Patrick Barry
>Priority: Major
>
> According to HTTP 1.1 spec, content-length header should never be sent with 
> Transfer-Encoding: chunked on request.  However, when you send a request 
> using a non-body Method like GET or DELETE using this async client, it is 
> adding content-length:0 to the request.  This header should not be sent 
> according to RFC.
> Because it is sent, it causes the server that is responding to either reject 
> the request with a 400 or go down other paths. For example, Tomcat 9 chose to 
> accept the request but will close the connection, even if 
> Connection:Keep-Alive is requested on request.  This has major performance 
> drawbacks, and is only one way a server chose to handle this.
>  
> As per RFC 7230:
> 
> A sender MUST NOT send a Content-Length header field in any message that 
> contains a Transfer-Encoding header field.
> 



--
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-2211) content-length header should not be sent when chunked encoding specified

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCLIENT-2211:
---

[~patrickjamesbarry] What makes you think HttpClient does that? Could you 
please provide a test case demostrating such behavior?

Oleg

> content-length header should not be sent when chunked encoding specified
> 
>
> Key: HTTPCLIENT-2211
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2211
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 5.1.3
>Reporter: Patrick Barry
>Priority: Major
>
> According to HTTP 1.1 spec, content-length header should never be sent with 
> Transfer-Encoding: chunked on request.  However, when you send a request 
> using a non-body Method like GET or DELETE using this async client, it is 
> adding content-length:0 to the request.  This header should not be sent 
> according to RFC.
> Because it is sent, it causes the server that is responding to either reject 
> the request with a 400 or go down other paths. For example, Tomcat 9 chose to 
> accept the request but will close the connection, even if 
> Connection:Keep-Alive is requested on request.  This has major performance 
> drawbacks, and is only one way a server chose to handle this.
>  
> As per RFC 7230:
> 
> A sender MUST NOT send a Content-Length header field in any message that 
> contains a Transfer-Encoding header field.
> 



--
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] [Resolved] (HTTPCORE-710) Async client hangs if remote peer closes connection during TLS handshake

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski resolved HTTPCORE-710.

Fix Version/s: 5.2-beta2
   Resolution: Fixed

> Async client hangs if remote peer closes connection during TLS handshake
> 
>
> Key: HTTPCORE-710
> URL: https://issues.apache.org/jira/browse/HTTPCORE-710
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 5.2-beta1
>Reporter: Ryan Schmitt
>Priority: Blocker
> Fix For: 5.2-beta2
>
>
> I discovered a regression in the 5.2 async client while testing various 
> failure modes for TLS negotiation. In this case, the failure condition is 
> when the client sends a Client Hello and the server responds by immediately 
> closing the connection (with a FIN in this case, not a RST). With client 
> version 5.1.3, when this happened the client would simply throw an exception 
> with the following cause:
> {code}
> Caused by:
> org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
> at 
> app//org.apache.hc.core5.http2.impl.nio.ClientHttpProtocolNegotiator.inputReady(ClientHttpProtocolNegotiator.java:165)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:574)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
> at 
> app//org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
> at 
> app//org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> ... 5 more
> {code}
> Now, on the latest 5.2 nightly, no exception gets thrown at all; whereas 
> {{SSLIOSession}} used to call into 
> {{ClientHttpProtocolNegotiator#inputReady}}, it now ends up in 
> {{AbstractHttp1IOEventHandler#inputReady}} and then 
> {{AbstractHttp1StreamDuplexer#onInput}}, which placidly requests a graceful 
> shutdown by following this code path:
> {code:java}
> if (endOfStream && !inbuf.hasData()) {
> if (outputIdle() && inputIdle()) {
> requestShutdown(CloseMode.GRACEFUL);
> {code}
> However, even if I force the code to take the other path 
> ({{shutdownSession(new ConnectionClosedException("Connection closed by 
> peer"))}}), the client still just hangs forever. Something, presumably 
> {{SSLIOSession}} itself, is forgetting to invoke the appropriate callback to 
> fail the handshake in this situation.



--
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] [Resolved] (HTTPCLIENT-2080) HttpRequestRetryStrategy doesn't delay the retry if IOException occurs

[Oleg Kalnichevski (Jira)]

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

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

Implemented by https://github.com/apache/httpcomponents-client/pull/356

> HttpRequestRetryStrategy doesn't delay the retry if IOException occurs
> --
>
> Key: HTTPCLIENT-2080
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2080
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Hendra
>Priority: Major
> Fix For: 5.2-alpha2
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> In httpclient5, HttpRequestRetryStrategy has introduced a new feature 
> retryInterval which determines the interval between subsequent retries. In 
> case there are IOExceptions occur, the retry happens but without any delays.
>  
> There might be some bugs in HttpRequestRetryExec.class implementation.



--
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] [Reopened] (HTTPCLIENT-2080) HttpRequestRetryStrategy doesn't delay the retry if IOException occurs

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski reopened HTTPCLIENT-2080:
---

> HttpRequestRetryStrategy doesn't delay the retry if IOException occurs
> --
>
> Key: HTTPCLIENT-2080
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2080
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 5.0
>Reporter: Hendra
>Priority: Major
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> In httpclient5, HttpRequestRetryStrategy has introduced a new feature 
> retryInterval which determines the interval between subsequent retries. In 
> case there are IOExceptions occur, the retry happens but without any delays.
>  
> There might be some bugs in HttpRequestRetryExec.class implementation.



--
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] [Resolved] (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:all-tabpanel
 ]

Oleg Kalnichevski resolved HTTPCLIENT-2210.
---
Resolution: Fixed

Fixed with 
[https://github.com/apache/httpcomponents-website/commit/f2cb879f4362d25e9d23b6357538fcffcd9c1195]

Oleg

> 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

[jira] [Commented] (HTTPCORE-710) Async client hangs if remote peer closes connection during TLS handshake

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-710:


[~rschmitt] It turned out that for some bizarre reasons in case of some TLS 
handshake failures the standard TLS engine returns the end of the data stream 
instead of throwing a TLS handshake exception, for instance in case of a TLS 
version mismatch. This behavior sounds wrong to me. Regardless, I added a 
sage-guard that signals a TLS handshake failure if the engine returns the end 
of data stream prior to proper completion of the TLS handshake. This fixes the 
issue for me locally. I verified it with your test case and also added a test 
case to the TLS integration test suite.

Please review.

Please also do consider adding more test cases to the `TLSIntegrationTest` 
suite [1] if you can think of any special conditions that are presently not 
covered.

Oleg

[1] 
https://github.com/apache/httpcomponents-core/blob/HTTPCORE-710/httpcore5-testing/src/test/java/org/apache/hc/core5/testing/nio/TLSIntegrationTest.java

> Async client hangs if remote peer closes connection during TLS handshake
> 
>
> Key: HTTPCORE-710
> URL: https://issues.apache.org/jira/browse/HTTPCORE-710
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 5.2-beta1
>Reporter: Ryan Schmitt
>Priority: Blocker
>
> I discovered a regression in the 5.2 async client while testing various 
> failure modes for TLS negotiation. In this case, the failure condition is 
> when the client sends a Client Hello and the server responds by immediately 
> closing the connection (with a FIN in this case, not a RST). With client 
> version 5.1.3, when this happened the client would simply throw an exception 
> with the following cause:
> {code}
> Caused by:
> org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
> at 
> app//org.apache.hc.core5.http2.impl.nio.ClientHttpProtocolNegotiator.inputReady(ClientHttpProtocolNegotiator.java:165)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:574)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
> at 
> app//org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
> at 
> app//org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> ... 5 more
> {code}
> Now, on the latest 5.2 nightly, no exception gets thrown at all; whereas 
> {{SSLIOSession}} used to call into 
> {{ClientHttpProtocolNegotiator#inputReady}}, it now ends up in 
> {{AbstractHttp1IOEventHandler#inputReady}} and then 
> {{AbstractHttp1StreamDuplexer#onInput}}, which placidly requests a graceful 
> shutdown by following this code path:
> {code:java}
> if (endOfStream && !inbuf.hasData()) {
> if (outputIdle() && inputIdle()) {
> requestShutdown(CloseMode.GRACEFUL);
> {code}
> However, even if I force the code to take the other path 
> ({{shutdownSession(new ConnectionClosedException("Connection closed by 
> peer"))}}), the client still just hangs forever. Something, presumably 
> {{SSLIOSession}} itself, is forgetting to invoke the appropriate callback to 
> fail the handshake in this situation.



--
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] (HTTPCORE-710) Async client hangs if remote peer closes connection during TLS handshake

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-710:


[~rschmitt] I can reproduce the defect locally with your reproducer. Many 
thanks for that.

I am however not able to pinpoint the cause of the issue right away. Everything 
appears to be OK at the TLS level but for whatever reason the HTTP/1,1 protocol 
handler appears to fail to propogate a TLS protocol failure to the application 
layer. I am now trying to reproduce the same behavior with HttpCore alone and 
our own testing infrastructure. Please bear with me.

Oleg  

> Async client hangs if remote peer closes connection during TLS handshake
> 
>
> Key: HTTPCORE-710
> URL: https://issues.apache.org/jira/browse/HTTPCORE-710
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 5.2-beta1
>Reporter: Ryan Schmitt
>Priority: Blocker
>
> I discovered a regression in the 5.2 async client while testing various 
> failure modes for TLS negotiation. In this case, the failure condition is 
> when the client sends a Client Hello and the server responds by immediately 
> closing the connection (with a FIN in this case, not a RST). With client 
> version 5.1.3, when this happened the client would simply throw an exception 
> with the following cause:
> {code}
> Caused by:
> org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
> at 
> app//org.apache.hc.core5.http2.impl.nio.ClientHttpProtocolNegotiator.inputReady(ClientHttpProtocolNegotiator.java:165)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:574)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
> at 
> app//org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
> at 
> app//org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> ... 5 more
> {code}
> Now, on the latest 5.2 nightly, no exception gets thrown at all; whereas 
> {{SSLIOSession}} used to call into 
> {{ClientHttpProtocolNegotiator#inputReady}}, it now ends up in 
> {{AbstractHttp1IOEventHandler#inputReady}} and then 
> {{AbstractHttp1StreamDuplexer#onInput}}, which placidly requests a graceful 
> shutdown by following this code path:
> {code:java}
> if (endOfStream && !inbuf.hasData()) {
> if (outputIdle() && inputIdle()) {
> requestShutdown(CloseMode.GRACEFUL);
> {code}
> However, even if I force the code to take the other path 
> ({{shutdownSession(new ConnectionClosedException("Connection closed by 
> peer"))}}), the client still just hangs forever. Something, presumably 
> {{SSLIOSession}} itself, is forgetting to invoke the appropriate callback to 
> fail the handshake in this situation.



--
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=17513410#comment-17513410
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-2210:
---

[~enterit] One just need to change the log4 config snippets in this document 
[https://github.com/apache/httpcomponents-website/blob/master/src/site/markdown/httpcomponents-client-5.1.x/logging.md]

Oleg

> 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

[jira] [Commented] (HTTPCORE-710) Async client hangs if remote peer closes connection during TLS handshake

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-710:


[~rschmitt] Would you be able to share the reproducer with me?

Oleg

> Async client hangs if remote peer closes connection during TLS handshake
> 
>
> Key: HTTPCORE-710
> URL: https://issues.apache.org/jira/browse/HTTPCORE-710
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 5.2-beta1
>Reporter: Ryan Schmitt
>Priority: Blocker
>
> I discovered a regression in the 5.2 async client while testing various 
> failure modes for TLS negotiation. In this case, the failure condition is 
> when the client sends a Client Hello and the server responds by immediately 
> closing the connection (with a FIN in this case, not a RST). With client 
> version 5.1.3, when this happened the client would simply throw an exception 
> with the following cause:
> {code}
> Caused by:
> org.apache.hc.core5.http2.impl.nio.ProtocolNegotiationException: 
> Unexpected input
> at 
> app//org.apache.hc.core5.http2.impl.nio.ClientHttpProtocolNegotiator.inputReady(ClientHttpProtocolNegotiator.java:165)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.decryptData(SSLIOSession.java:574)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession.access$400(SSLIOSession.java:72)
> at 
> app//org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:172)
> at 
> app//org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:131)
> at 
> app//org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> ... 5 more
> {code}
> Now, on the latest 5.2 nightly, no exception gets thrown at all; whereas 
> {{SSLIOSession}} used to call into 
> {{ClientHttpProtocolNegotiator#inputReady}}, it now ends up in 
> {{AbstractHttp1IOEventHandler#inputReady}} and then 
> {{AbstractHttp1StreamDuplexer#onInput}}, which placidly requests a graceful 
> shutdown by following this code path:
> {code:java}
> if (endOfStream && !inbuf.hasData()) {
> if (outputIdle() && inputIdle()) {
> requestShutdown(CloseMode.GRACEFUL);
> {code}
> However, even if I force the code to take the other path 
> ({{shutdownSession(new ConnectionClosedException("Connection closed by 
> peer"))}}), the client still just hangs forever. Something, presumably 
> {{SSLIOSession}} itself, is forgetting to invoke the appropriate callback to 
> fail the handshake in this situation.



--
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] (HTTPCORE-692) H2 should throw illegal header exception when use Host header as Connection header

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-692:


[~rschmitt] Sounds correct to me. As long as the signature matches the request 
URI, connection specific headers should get correctly populated by the protocol 
handlers automatically without invalidating the signature.

Oleg

> H2 should throw illegal header exception when use Host header as Connection 
> header
> --
>
> Key: HTTPCORE-692
> URL: https://issues.apache.org/jira/browse/HTTPCORE-692
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.1
> Environment: Macos 11.6
> openjdk 11.0.12 2021-07-20
>Reporter: yinwoods
>Priority: Minor
>  Labels: easyfix
> Fix For: 5.2-beta1
>
>   Original Estimate: 1h
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I notice org/apache/hc/core5/http2/impl/DefaultH2RequestConverter.java:105 
> throws ProtocolException when header contains Connection. When header contains
> host/upgrade/transfer-encoding header, should it throws ProtocolException 
> eigther?
>  
> demo code as below, when I comment Host header, I got 200 response, and when 
> uncomment, got 400 bad request.
> {code:java}
> //
> public class HttpUtilTest {
> public static void main(String[] args) throws Exception {
> HttpContext httpContext = new BasicHttpContext();
> BasicCookieStore cookie = new BasicCookieStore();
> httpContext.setAttribute(HttpClientContext.COOKIE_STORE, cookie);
> SimpleHttpRequest request = SimpleRequestBuilder.create(Method.GET)
> .setUri("https://zzpro2.wmeimob.cn/api/user;)
> .addHeader("User-Agent", "zhenzhu/3.3.3.0 CFNetwork/1128.0.1 
> Darwin/19.6.0")
> .addHeader("loading", "false")
> .addHeader("Accept-Language", "zh-cn")
> .addHeader("toast", "true")
> // .addHeader("Host", "zzpro2.wmeimob.cn")
> .addHeader("Accept-Encoding", "gzip, deflate, br")
> .build();
> SSLContext sslcontext = CipherSuitesUtil.createSslContext();
> final TlsStrategy tlsStrategy = new 
> DefaultClientTlsStrategy(sslcontext, NoopHostnameVerifier.INSTANCE);
> final PoolingAsyncClientConnectionManager connectionManager = 
> PoolingAsyncClientConnectionManagerBuilder
> .create()
> .setTlsStrategy(tlsStrategy)
> .build();
> IOReactorConfig ioConfig =
> IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setSoTimeout(Timeout.ofMilliseconds(5000))
> .setIoThreadCount(4)
> .setSelectInterval(TimeValue.ofMilliseconds(500))
> .build();
> RequestConfig requestConfig =
> RequestConfig.custom()
> .setCookieSpec(StandardCookieSpec.RELAXED)
> .setConnectTimeout(Timeout.ofMilliseconds(5000))
> .setResponseTimeout(Timeout.ofMilliseconds(5000))
> .setRedirectsEnabled(true)
> .setMaxRedirects(10)
> .build();
> HttpAsyncClientBuilder clientBuilder = HttpAsyncClients.custom()
> .setDefaultRequestConfig(requestConfig)
> .setRedirectStrategy(CustomRedirectStrategy.INSTANCE)
> .setConnectionManager(connectionManager)
> .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
> .setIOReactorConfig(ioConfig);
> CloseableHttpAsyncClient client = clientBuilder.build();
> client.start();
> client.execute(request, httpContext, new FutureCallback<>() {
> @Override
> public void completed(SimpleHttpResponse result) {
> try {
> System.out.println(result);
> } catch (Exception e) {
> }
> }
> @Override
> public void failed(Exception ex) {
> ex.printStackTrace();
> }
> @Override
> public void cancelled() {
> System.out.println("cancelled");
> }
> });
> Thread.sleep(50 * 1000);
> client.close();
> }
> }
> {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] (HTTPCORE-692) H2 should throw illegal header exception when use Host header as Connection header

[Oleg Kalnichevski (Jira)]

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

Oleg Kalnichevski commented on HTTPCORE-692:


[~rschmitt] Generally one should not meddle with connection specific headers at 
all. Protocol handlers are going to populate those headers as required. 
However, when necessary one can use a request or execution interceptor to do 
so. The protocol version should be available in the execution of context passed 
to the interceptor.

Oleg

> H2 should throw illegal header exception when use Host header as Connection 
> header
> --
>
> Key: HTTPCORE-692
> URL: https://issues.apache.org/jira/browse/HTTPCORE-692
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.1
> Environment: Macos 11.6
> openjdk 11.0.12 2021-07-20
>Reporter: yinwoods
>Priority: Minor
>  Labels: easyfix
> Fix For: 5.2-beta1
>
>   Original Estimate: 1h
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> I notice org/apache/hc/core5/http2/impl/DefaultH2RequestConverter.java:105 
> throws ProtocolException when header contains Connection. When header contains
> host/upgrade/transfer-encoding header, should it throws ProtocolException 
> eigther?
>  
> demo code as below, when I comment Host header, I got 200 response, and when 
> uncomment, got 400 bad request.
> {code:java}
> //
> public class HttpUtilTest {
> public static void main(String[] args) throws Exception {
> HttpContext httpContext = new BasicHttpContext();
> BasicCookieStore cookie = new BasicCookieStore();
> httpContext.setAttribute(HttpClientContext.COOKIE_STORE, cookie);
> SimpleHttpRequest request = SimpleRequestBuilder.create(Method.GET)
> .setUri("https://zzpro2.wmeimob.cn/api/user;)
> .addHeader("User-Agent", "zhenzhu/3.3.3.0 CFNetwork/1128.0.1 
> Darwin/19.6.0")
> .addHeader("loading", "false")
> .addHeader("Accept-Language", "zh-cn")
> .addHeader("toast", "true")
> // .addHeader("Host", "zzpro2.wmeimob.cn")
> .addHeader("Accept-Encoding", "gzip, deflate, br")
> .build();
> SSLContext sslcontext = CipherSuitesUtil.createSslContext();
> final TlsStrategy tlsStrategy = new 
> DefaultClientTlsStrategy(sslcontext, NoopHostnameVerifier.INSTANCE);
> final PoolingAsyncClientConnectionManager connectionManager = 
> PoolingAsyncClientConnectionManagerBuilder
> .create()
> .setTlsStrategy(tlsStrategy)
> .build();
> IOReactorConfig ioConfig =
> IOReactorConfig.custom()
> .setSoKeepAlive(true)
> .setSoTimeout(Timeout.ofMilliseconds(5000))
> .setIoThreadCount(4)
> .setSelectInterval(TimeValue.ofMilliseconds(500))
> .build();
> RequestConfig requestConfig =
> RequestConfig.custom()
> .setCookieSpec(StandardCookieSpec.RELAXED)
> .setConnectTimeout(Timeout.ofMilliseconds(5000))
> .setResponseTimeout(Timeout.ofMilliseconds(5000))
> .setRedirectsEnabled(true)
> .setMaxRedirects(10)
> .build();
> HttpAsyncClientBuilder clientBuilder = HttpAsyncClients.custom()
> .setDefaultRequestConfig(requestConfig)
> .setRedirectStrategy(CustomRedirectStrategy.INSTANCE)
> .setConnectionManager(connectionManager)
> .setVersionPolicy(HttpVersionPolicy.NEGOTIATE)
> .setIOReactorConfig(ioConfig);
> CloseableHttpAsyncClient client = clientBuilder.build();
> client.start();
> client.execute(request, httpContext, new FutureCallback<>() {
> @Override
> public void completed(SimpleHttpResponse result) {
> try {
> System.out.println(result);
> } catch (Exception e) {
> }
> }
> @Override
> public void failed(Exception ex) {
> ex.printStackTrace();
> }
> @Override
> public void cancelled() {
> System.out.println("cancelled");
> }
> });
> Thread.sleep(50 * 1000);
> client.close();
> }
> }
> {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] [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] [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