Re: [VOTE] Release HttpClient 5.4.1 based on RC1

[Michael Osipov]

+1

On 2024/10/25 07:50:31 Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.4.1.
> 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.4.1-RC1/RELEASE_NOTES-5.4.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1183/org/apache/httpcomponents/client5/
> 
> Git Tag: 5.4.1-RC1
>  https://github.com/apache/httpcomponents-client/tree/5.4.1-RC1
> 
> Packages:
>  https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.4.1-RC1
>  revision 72620
> 
> Hashes:
>  
> fc664652b34b8fe34c2f511ca2633254bfd4721b78cfde06a2de57f973eeedb31e3eb4e2b4d03180009b75cad2e29617b10996d93bf3f51ef45dd911e3cd082e
>  *httpcomponents-client-5.4.1-bin.zip httpcomponents-client-5.4.1-bin.zip
>  
> 4c53c4cae428d5608c5b671aeef33a38ec0c2046fbcf735068ddf651addbf6958c2395fc1dc50f4808dd2d092940c8d44ad4af5c8f61a2a6d8220826932b7732
>  *httpcomponents-client-5.4.1-src.zip httpcomponents-client-5.4.1-src.zip
>  
> df807808c02bbb754f8b8f0f03712186ebe6a4afc375568c4c94acc89c6e759d919562348549f24580cf6332bc4e5c67dcbfeb988220ae5be4531326aa933629
>  *httpcomponents-client-5.4.1-src.tar.gz 
> httpcomponents-client-5.4.1-src.tar.gz
>  
> 6269db4aca700e75abcf593330a283cd0b85d2d044807a0cefd61bcb348bf9db9d6a342c0b3c4ea4797bd95335b691eadaec9377a97d0e667ae411b7c49b865d
>  *httpcomponents-client-5.4.1-bin.tar.gz 
> httpcomponents-client-5.4.1-bin.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpclient/KEYS
> 
> --
> Vote: HttpClient 5.4.1 release
> [ ] +1 Release the packages as HttpClient 5.4.1.
> [ ] -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

Re: [VOTE] Release HttpCore 5.3.1 based on RC1

[Michael Osipov]

+1

On 2024/10/19 10:32:19 Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpCore 5.3.1.
> 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.3.1-RC1/RELEASE_NOTES-5.3.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1182/org/apache/httpcomponents/core5/
> 
> Git Tag: 5.3.1-RC1
>  https://github.com/apache/httpcomponents-core/tree/5.3.1-RC1
> 
> Packages:
>  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.3.1-RC1
>  revision 72432
> 
> Hashes:
>  
> 6ef6ef8f6444ef1037c0822de337c6976493d74882bba382a4146e9023e4bbfce7bcd537b7039c9dde9eb5baaec540e8631f79ecc826d5b072e01fc3b857890b
>  *httpcomponents-core-5.3.1-src.zip httpcomponents-core-5.3.1-src.zip
>  
> cbd4a9e0e35a415e9e8e1b2c0896c4b361df58e149068021fae9afef631310ee3a50f6758652a4d3def86ee59628c7975bc945679c73a0206ed6165594e4cebb
>  *httpcomponents-core-5.3.1-bin.tar.gz httpcomponents-core-5.3.1-bin.tar.gz
>  
> d11fb2b7473b15576a9a0cd1140e20bdb93fa3dd4a6486ea9b039cb2c13ab7aed0c016a8c54550e3d7db956b3ae43ed6bdffc8ffbc1f930376c5aacd29720cda
>  *httpcomponents-core-5.3.1-src.tar.gz httpcomponents-core-5.3.1-src.tar.gz
>  
> 4ca418e0b3f6cf79a65e77be211e7d9d79de8cd789a4bc4d854b4256dd087c433584364148aa36c1203122745070cd4b6d1feac128bd20dc3a9bdecc7a97e196
>  *httpcomponents-core-5.3.1-bin.zip httpcomponents-core-5.3.1-bin.zip
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpcore/KEYS
> 
> --
> Vote: HttpCore 5.3.1 release
> [ ] +1 Release the packages as HttpCore 5.3.1.
> [ ] -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

[jira] [Commented] (HTTPCORE-771) Exception when using HttpClient 5.4 with Oracle Java 8

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-771:
-

LGTM

> Exception when using HttpClient 5.4 with Oracle Java 8
> --
>
> Key: HTTPCORE-771
> URL: https://issues.apache.org/jira/browse/HTTPCORE-771
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.3
> Environment: Oracle Java 8 (Windows and Linux)
>Reporter: Bernhard Fey
>Priority: Minor
> Fix For: 5.3.1, 5.4-alpha1
>
> Attachments: J8HttpsErrorTest.java
>
>
> When updating to version 5.4 our tests with Oracle Java 8 fail with the 
> following exception:
> java.lang.UnsupportedOperationException: method is not supported because of 
> the TLS half-close policy
>     at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:765)
>     at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:743)
>     at 
> org.apache.hc.core5.http.impl.io.BHttpConnectionBase.close(BHttpConnectionBase.java:255)
>     at 
> org.apache.hc.core5.http.impl.io.DefaultBHttpClientConnection.close(DefaultBHttpClientConnection.java:71)
>     at 
> org.apache.hc.client5.http.impl.io.DefaultManagedHttpClientConnection.close(DefaultManagedHttpClientConnection.java:176)
>     at 
> org.apache.hc.core5.pool.PoolEntry.discardConnection(PoolEntry.java:180)
>     at 
> org.apache.hc.core5.pool.StrictConnPool$PerRoutePool.shutdown(StrictConnPool.java:839)
>     at org.apache.hc.core5.pool.StrictConnPool.close(StrictConnPool.java:142)
>     at 
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.close(PoolingHttpClientConnectionManager.java:277)
>     at 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.close(InternalHttpClient.java:198)
>     at 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.close(InternalHttpClient.java:188)
>     at J8HttpsErrorTest.main(J8HttpsErrorTest.java:22)
> I have attached a test class, which fails in Oracle Java 8 with the above 
> exception, but finishes correctly with Java 11 or OpenJDK 8.
> It has been tested on Windows 10, but the Oracle Java 8 exception also occurs 
> on Linux in our integration.
> The specific VM the exception was reproduced with is "Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 1.8.0_411-b09".



--
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] (HTTPCORE-771) Exception when using HttpClient 5.4 with Oracle Java 8

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-771:
-

I comment in the code would be helpful.

> Exception when using HttpClient 5.4 with Oracle Java 8
> --
>
> Key: HTTPCORE-771
> URL: https://issues.apache.org/jira/browse/HTTPCORE-771
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.3
> Environment: Oracle Java 8 (Windows and Linux)
>Reporter: Bernhard Fey
>Priority: Minor
> Fix For: 5.3.1, 5.4-alpha1
>
> Attachments: J8HttpsErrorTest.java
>
>
> When updating to version 5.4 our tests with Oracle Java 8 fail with the 
> following exception:
> java.lang.UnsupportedOperationException: method is not supported because of 
> the TLS half-close policy
>     at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:765)
>     at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:743)
>     at 
> org.apache.hc.core5.http.impl.io.BHttpConnectionBase.close(BHttpConnectionBase.java:255)
>     at 
> org.apache.hc.core5.http.impl.io.DefaultBHttpClientConnection.close(DefaultBHttpClientConnection.java:71)
>     at 
> org.apache.hc.client5.http.impl.io.DefaultManagedHttpClientConnection.close(DefaultManagedHttpClientConnection.java:176)
>     at 
> org.apache.hc.core5.pool.PoolEntry.discardConnection(PoolEntry.java:180)
>     at 
> org.apache.hc.core5.pool.StrictConnPool$PerRoutePool.shutdown(StrictConnPool.java:839)
>     at org.apache.hc.core5.pool.StrictConnPool.close(StrictConnPool.java:142)
>     at 
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.close(PoolingHttpClientConnectionManager.java:277)
>     at 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.close(InternalHttpClient.java:198)
>     at 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.close(InternalHttpClient.java:188)
>     at J8HttpsErrorTest.main(J8HttpsErrorTest.java:22)
> I have attached a test class, which fails in Oracle Java 8 with the above 
> exception, but finishes correctly with Java 11 or OpenJDK 8.
> It has been tested on Windows 10, but the Oracle Java 8 exception also occurs 
> on Linux in our integration.
> The specific VM the exception was reproduced with is "Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 1.8.0_411-b09".



--
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-2345) Exception when using HttpClient 5.4 with Oracle Java 8

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2345:


If this works with OpenJDK, then I would recommend to open an issue with MOSC 
and have the actual fix backported to Oracle Java 8 after all. totally unclear, 
why this hasn't been cherry-picked to Oracle's distro.

> Exception when using HttpClient 5.4 with Oracle Java 8
> --
>
> Key: HTTPCLIENT-2345
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2345
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 5.4
> Environment: Oracle Java 8 (Windows and Linux)
>Reporter: Bernhard Fey
>Priority: Minor
> Attachments: J8HttpsErrorTest.java
>
>
> When updating to version 5.4 our tests with Oracle Java 8 fail with the 
> following exception:
> java.lang.UnsupportedOperationException: method is not supported because of 
> the TLS half-close policy
>     at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:765)
>     at sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:743)
>     at 
> org.apache.hc.core5.http.impl.io.BHttpConnectionBase.close(BHttpConnectionBase.java:255)
>     at 
> org.apache.hc.core5.http.impl.io.DefaultBHttpClientConnection.close(DefaultBHttpClientConnection.java:71)
>     at 
> org.apache.hc.client5.http.impl.io.DefaultManagedHttpClientConnection.close(DefaultManagedHttpClientConnection.java:176)
>     at 
> org.apache.hc.core5.pool.PoolEntry.discardConnection(PoolEntry.java:180)
>     at 
> org.apache.hc.core5.pool.StrictConnPool$PerRoutePool.shutdown(StrictConnPool.java:839)
>     at org.apache.hc.core5.pool.StrictConnPool.close(StrictConnPool.java:142)
>     at 
> org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.close(PoolingHttpClientConnectionManager.java:277)
>     at 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.close(InternalHttpClient.java:198)
>     at 
> org.apache.hc.client5.http.impl.classic.InternalHttpClient.close(InternalHttpClient.java:188)
>     at J8HttpsErrorTest.main(J8HttpsErrorTest.java:22)
> I have attached a test class, which fails in Oracle Java 8 with the above 
> exception, but finishes correctly with Java 11 or OpenJDK 8.
> It has been tested on Windows 10, but the Oracle Java 8 exception also occurs 
> on Linux in our integration.
> The specific VM the exception was reproduced with is "Oracle Corporation Java 
> HotSpot(TM) 64-Bit Server VM 1.8.0_411-b09".



--
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-2322) Javadoc lists each class twice

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2322:


Yes.

> Javadoc lists each class twice
> --
>
> Key: HTTPCLIENT-2322
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2322
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Konrad Windszus
>Priority: Minor
>
> The classes overview at 
> https://hc.apache.org/httpcomponents-client-5.3.x/current/httpclient5/apidocs/allclasses-frame.html
>  lists each class twice.



--
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

Re: [VOTE][LAZY] Release HttpComponents Parent 14 based on RC1

[Michael Osipov]

+1

On 2024/09/26 07:33:22 Oleg Kalnichevski wrote:
> Please lazy vote on releasing HttpComponents Parent 14 based on RC1.
> 
> 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 one
> binding +1 vote is cast and there are more +1 than -1 votes.
> 
> Maven repo:
> 
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1181/org/apache/httpcomponents/httpcomponents-parent/14
> 
> Git Tag:
> 
> https://github.com/apache/httpcomponents-parent/tree/14-RC1
> 
> Dist:
> 
> https://dist.apache.org/repos/dist/dev/httpcomponents/parent-14-RC1/
> 
> Hash:
> 5ca372fd0a7952ba86fbc8f11e92a8d968ce89a1da6ddaf0c6feba2ba797d23525e96d2
> 1b891e74698a8d079c402f643ba81d2a09cacebeb22335de0d60047b3 
> httpcomponents-parent-14-source.zip
> 
> -
> Vote:
> [ ] +1
> [ ] -1
> -
> 
> -
> 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 HttpClient 5.4 based on RC1

[Michael Osipov]

+1

On 2024/09/16 15:40:31 Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.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/httpclient-5.4-RC1/RELEASE_NOTES-5.4.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1179/org/apache/httpcomponents/client5/
> 
> Git Tag: 5.4-RC1
>  https://github.com/apache/httpcomponents-client/tree/5.4-RC1
> 
> Packages:
>  https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.4-RC1
>  revision 71615
> 
> Hashes:
>  
> d38333ac61f422f7486b371cee3eb97bba2b754ce4c30e97b67e8b3dc816b1ec0ca8533c7ec4dfe030e1bee928ce4e2a15c4dba7b74e5d05cdbd7c7a35aa95e0
>  *httpcomponents-client-5.4-src.tar.gz httpcomponents-client-5.4-src.tar.gz
>  
> a936435fa5cb62a5acfab1622e3eee9ee0e5e72c3389814b68e8817c927391ccd223f74810d23b651b0843c6dc4410612168d6b6310999c02e344a861195540e
>  *httpcomponents-client-5.4-bin.zip httpcomponents-client-5.4-bin.zip
>  
> fd4c5a584ac24b798645d908480e0b078685f232972dbe458b77e11499cf7b9e1743959ffa449f4f9cbc153380aa0d8c6fb3f70483fb40ddc561f51801929e9c
>  *httpcomponents-client-5.4-src.zip httpcomponents-client-5.4-src.zip
>  
> 80d6bed4f9fa6fd51336b8332221d9e727c2c6e849c400c01dd04a8e26e042b7516d9013f16b3c17e4aa7f5fc4549798c097a81ad8b2e2b73dd478ab2cc51042
>  *httpcomponents-client-5.4-bin.tar.gz httpcomponents-client-5.4-bin.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpclient/KEYS
> 
> --
> Vote: HttpClient 5.4 release
> [ ] +1 Release the packages as HttpClient 5.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

[jira] [Commented] (HTTPCLIENT-2337) Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2337:


[~winfriedgerlach], BTW you missed out to add a banana to the CN!

> Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory
> -
>
> Key: HTTPCLIENT-2337
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2337
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.14, 5.3.1, 5.4-beta1
>Reporter: Winfried Gerlach
>Priority: Major
> Fix For: 5.4-beta2
>
> Attachments: example-cert.pem, image-2024-09-03-08-43-06-757.png
>
>
> We noticed that in both Apache HTTP Client 4.x and 5.x, 
> {{SSLConnectionSocketFactory}} logs the X500Principal on DEBUG level without 
> sanitizing the fields. If, e.g., the CN contains control characters like 
> {{\b}} or {{{}\n{}}}, this could be used by an attacker to tamper with the 
> log of the application (remove stuff, add line breaks etc.).
> !image-2024-09-03-08-43-06-757.png!
> In the screenshot, the CN has a \b after "Control", so the last letter "l" is 
> removed from the log.
> We don't consider this behavior particularly dangerous because it happens on 
> debug level only and the logger can also be turned off completely if needed.
> You may still want to think about sanitizing the RDN values before logging or 
> somehow avoiding to log the X500Principal completely.



--
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] [Comment Edited] (HTTPCLIENT-2337) Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2337 at 9/5/24 10:12 AM:
-

I see at least three ways to approach this:

* Get the DER value and process manually with Kerby ASN.1 to process 
non-printable chars
* Parse as {{LdapName}} and process {{RDNs}} separately
* For the poor:
{code:java}
String value = 
toExtendedRFC2253String(x509Cert.getSubjectX500Principal());
StringBuilder sb = new StringBuilder();
for (char c : value.toCharArray()) {
if (Character.isISOControl(c)) {
sb.append("\\x").append(String.format("%02x", 
(int) c));
} else {
sb.append(c);
}
}

System.out.println(sb);
{code}
Output:
{code}
CN=\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08\x08This🙈CN🌴Has\x09Ctrl\x08And\x0cOtherSpecial\x0aChars\\x0d,O=Test
{code}


was (Author: michael-o):
I see at least three ways to approach this:

* Get the DER value and process manually with Kerby ASN.1 to process 
non-printable chars
* Parse as {{LdapName}} and process {{RDNs}} separately
* For the poor:
{code:java}
String value = 
toExtendedRFC2253String(x509Cert.getSubjectX500Principal());
StringBuilder sb = new StringBuilder();
for (char c : value.toCharArray()) {
if (Character.isISOControl(c)) {
sb.append("\\x").append(String.format("%02x", 
(int) c));
} else {
sb.append(c);
}
}

System.out.println(sb);
{code}

> Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory
> -
>
> Key: HTTPCLIENT-2337
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2337
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.14, 5.3.1, 5.4-beta1
>Reporter: Winfried Gerlach
>Priority: Major
> Fix For: 5.4-beta2
>
> Attachments: example-cert.pem, image-2024-09-03-08-43-06-757.png
>
>
> We noticed that in both Apache HTTP Client 4.x and 5.x, 
> {{SSLConnectionSocketFactory}} logs the X500Principal on DEBUG level without 
> sanitizing the fields. If, e.g., the CN contains control characters like 
> {{\b}} or {{{}\n{}}}, this could be used by an attacker to tamper with the 
> log of the application (remove stuff, add line breaks etc.).
> !image-2024-09-03-08-43-06-757.png!
> In the screenshot, the CN has a \b after "Control", so the last letter "l" is 
> removed from the log.
> We don't consider this behavior particularly dangerous because it happens on 
> debug level only and the logger can also be turned off completely if needed.
> You may still want to think about sanitizing the RDN values before logging or 
> somehow avoiding to log the X500Principal completely.



--
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-2337) Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2337:


Yes, the self-signed cert is 
[valid|https://lapo.it/asn1js/#MIIDUzCCAjugAwIBAgIEAWpeaTANBgkqhkiG9w0BAQsFADAhMR8wHQYDVQQDDBZJbnRlcm1lZGlhdGUtQ0EtVEVTVC0xMB4XDTI0MDkwNTA4NDMyNVoXDTI0MDkwNTA5NDMyNVowUzENMAsGA1UECgwEVGVzdDFCMEAGA1UEAww5CAgICAgICAgICAhUaGlz8J-ZiENO8J-MtEhhcwlDdHJsCEFuZAxPdGhlclNwZWNpYWwKQ2hhcnMNMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2zoZ1jrBB8IjAIJN98sOY9Mq38dzRMEXnQai_G3C53A8vRDS1Xd5ecLr3bIUT8mHOrIDY1BmUUxqy1-BQjLyZuDGhOxuplvVCYegku6Dl1mq3WYP57tzGr-YDWibMwnpVKihSooc4dkaJQdrPNRRLWKFAmliUMSwy-L8nfVMc4s3EFWZKbMM6aRNTw6lmjsOeW7Oq9ifEIrUWfSo5Mc9ugxfhQCzZqDVae0NOBrjWORO_J6Lq7sLoox9HpZrvG1DUtX16db5z_5BUUy9rtA_dqy2etj69-hEYloAVK1rJvoc_MPsVavv7o1nW9dWWh_b546nvCdMh-9gppr00xiQbwIDAQABo2EwXzAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwEwHwYDVR0jBBgwFoAUQvSi_0268glJ1fXaPesJy4HXQC0wHQYDVR0OBBYEFCLfsFq2yr6bKEBGWccyADf2bso5MA0GCSqGSIb3DQEBCwUAA4IBAQAqcSQFB0XS5s_NHIBUbDUjiNyvXBEoDCHet5swrZrALkH3bhwCo7NBISSL9E473ApTU7nRJdedyndHBaBTKmLuLVCYhMUXh9GN5In6BCjQa-C8wR2vnazadcyH5nOZMc0nf3nTlk0PmhcK4onReJvW1K_kst-yst9QZypbsqunOnk1JGJeRRsqMNkz1QRi8EWTCVb7eGRfS0KTFWbw5l0B_EThrTjsP7nB79Fvr4WpVa-Gnk71nm4jPG21joHsz7NqrO4MXZJpBAOb3DV4F_z8rOZcbj0P3MlN5pPR3PJLQXex-Bw_27uHs97-Acjl7SZ5Yh0p_1WTgj6Xgj-B7Syt]:
 contains {{UTF8String}}.

I do remember that we had such requests for header values and it was hard to 
make this better because when to know that the value is not suitable for 
printing. Let me check our code.

> Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory
> -
>
> Key: HTTPCLIENT-2337
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2337
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.14, 5.3.1, 5.4-beta1
>Reporter: Winfried Gerlach
>Priority: Major
> Fix For: 5.4-beta2
>
> Attachments: example-cert.pem, image-2024-09-03-08-43-06-757.png
>
>
> We noticed that in both Apache HTTP Client 4.x and 5.x, 
> {{SSLConnectionSocketFactory}} logs the X500Principal on DEBUG level without 
> sanitizing the fields. If, e.g., the CN contains control characters like 
> {{\b}} or {{{}\n{}}}, this could be used by an attacker to tamper with the 
> log of the application (remove stuff, add line breaks etc.).
> !image-2024-09-03-08-43-06-757.png!
> In the screenshot, the CN has a \b after "Control", so the last letter "l" is 
> removed from the log.
> We don't consider this behavior particularly dangerous because it happens on 
> debug level only and the logger can also be turned off completely if needed.
> You may still want to think about sanitizing the RDN values before logging or 
> somehow avoiding to log the X500Principal completely.



--
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-2337) Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2337:


I agree with [~ckozak].

> Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory
> -
>
> Key: HTTPCLIENT-2337
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2337
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.14, 5.3.1, 5.4-beta1
>Reporter: Winfried Gerlach
>Priority: Major
> Fix For: 5.4-beta2
>
> Attachments: image-2024-09-03-08-43-06-757.png
>
>
> We noticed that in both Apache HTTP Client 4.x and 5.x, 
> {{SSLConnectionSocketFactory}} logs the X500Principal on DEBUG level without 
> sanitizing the fields. If, e.g., the CN contains control characters like 
> {{\b}} or {{\n}}, this could be used by an attacker to tamper with the log of 
> the application (remove stuff, add line breaks etc.).
> !image-2024-09-03-08-43-06-757.png!
> In the screenshot, the CN has a \b after "Control", so the last letter "l" is 
> removed from the log.
> We don't consider this behavior particularly dangerous because it happens on 
> debug level only and the logger can also be turned off completely if needed.
> You may still want to think about sanitizing the RDN values before logging or 
> somehow avoid ing to log the X500Principal completely.



--
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-2337) Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2337:


[~winfriedgerlach], can you provide me an ASN.1 dump Base64 encoded of the cert?

> Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory
> -
>
> Key: HTTPCLIENT-2337
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2337
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.14, 5.3.1, 5.4-beta1
>Reporter: Winfried Gerlach
>Priority: Major
> Fix For: 5.4-beta2
>
> Attachments: image-2024-09-03-08-43-06-757.png
>
>
> We noticed that in both Apache HTTP Client 4.x and 5.x, 
> {{SSLConnectionSocketFactory}} logs the X500Principal on DEBUG level without 
> sanitizing the fields. If, e.g., the CN contains control characters like 
> {{\b}} or {{\n}}, this could be used by an attacker to tamper with the log of 
> the application (remove stuff, add line breaks etc.).
> !image-2024-09-03-08-43-06-757.png!
> In the screenshot, the CN has a \b after "Control", so the last letter "l" is 
> removed from the log.
> We don't consider this behavior particularly dangerous because it happens on 
> debug level only and the logger can also be turned off completely if needed.
> You may still want to think about sanitizing the RDN values before logging or 
> somehow avoid ing to log the X500Principal completely.



--
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-2337) Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2337:


Well, this can only happen the the CN is of value type DirectoryString, 
BMPString, UTF8String. In most cases it is PrintableString and the above cannot 
happen. I wonder which CA is willing to accept an CSR with such a subject value.

> Potentially unsafe logging of X500Principal in SSLConnectionSocketFactory
> -
>
> Key: HTTPCLIENT-2337
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2337
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Affects Versions: 4.5.14, 5.3.1, 5.4-beta1
>Reporter: Winfried Gerlach
>Priority: Major
> Fix For: 5.4-beta2
>
> Attachments: image-2024-09-03-08-43-06-757.png
>
>
> We noticed that in both Apache HTTP Client 4.x and 5.x, 
> {{SSLConnectionSocketFactory}} logs the X500Principal on DEBUG level without 
> sanitizing the fields. If, e.g., the CN contains control characters like 
> {{\b}} or {{\n}}, this could be used by an attacker to tamper with the log of 
> the application (remove stuff, add line breaks etc.).
> !image-2024-09-03-08-43-06-757.png!
> In the screenshot, the CN has a \b after "Control", so the last letter "l" is 
> removed from the log.
> We don't consider this behavior particularly dangerous because it happens on 
> debug level only and the logger can also be turned off completely if needed.
> You may still want to think about sanitizing the RDN values before logging or 
> somehow avoid ing to log the X500Principal completely.



--
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-1625) Completely overhaul GSS-API-based authentication backend

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-1625:


[~olegk], he is referring to a client initiated GSSException which has never 
left the client machine.

> Completely overhaul GSS-API-based authentication backend
> 
>
> Key: HTTPCLIENT-1625
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1625
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: Documentation, HttpClient (classic)
>Affects Versions: 4.5
>    Reporter: Michael Osipov
>Priority: Major
>  Labels: stuck, volunteers-wanted
>
> The current implementation does not reflect the way GSS-API-based 
> authentication should be done. It has several design flaws.
> This is an umbrella task for:
> 1. Deprecate all old classes
> 2. Investigate how it has to be plugged into HttpClient
> 3. Reimplement from scratch
> 4. Thoroughly test all new stuff
> 5. Rewrite documentation
> Design notes are canonically available under: 
> https://wiki.apache.org/HttpComponents/IssueTracking/HTTPCLIENT-1625



--
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

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

[Michael Osipov]

+1

On 2024/06/23 09:09:49 Oleg Kalnichevski wrote:
> Please vote on releasing these packages as HttpClient 5.4-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.4-beta1-RC1/RELEASE_NOTES-5.4.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1176/org/apache/httpcomponents/client5/
> 
> Git Tag: 5.4-beta1-RC1
>  https://github.com/apache/httpcomponents-client/tree/5.4-beta1-RC1
> 
> Packages:
>  
> https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.4-beta1-RC1
>  revision 69920
> 
> Hashes:
>  
> 753fc511610fb632ee97951bc096a00ac81f217c6d1218c9fac4351607913615c8e483aae736794da5db8753930ae5e2f501ce477da6d1eae01fd588cfa94633
>  httpcomponents-client-5.4-beta1-src.zip 
> httpcomponents-client-5.4-beta1-src.zip
>  
> cca2a3d5b21c8c0a9282a6e532733f1e007fad3358b962fd5481982214a842d7ef42f9da6fb96e3682a263ef00360842b835859f26ea1e0cb26565f988430c9a
>  httpcomponents-client-5.4-beta1-src.tar.gz 
> httpcomponents-client-5.4-beta1-src.tar.gz
>  
> 9c7fdb8f20790aa11e79d3771f03d0a085c4cb01e3d2f15f8eee77cb2f80901be7eebd33a1cea2b173f4863b7de0387644aaf18612fbf97fdba896e30f75d41f
>  httpcomponents-client-5.4-beta1-bin.zip 
> httpcomponents-client-5.4-beta1-bin.zip
>  
> 2ea0b7a95b327b3cee9b76262ce5c94933721cb894abd8c02de082e1ae7b3db17e8824ef76dafc0a64d4db26751ad4b6c0073b9cf575fb307fc57ad280c8c6e6
>  httpcomponents-client-5.4-beta1-bin.tar.gz 
> httpcomponents-client-5.4-beta1-bin.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpclient/KEYS
> 
> --
> Vote: HttpClient 5.4-beta1 release
> [ ] +1 Release the packages as HttpClient 5.4-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

Re: [VOTE] Release HttpCore 5.3-beta1 based on RC2

[Michael Osipov]

Am 2024-06-17 um 18:24 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.3-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/httpcore-5.3-beta1-RC2/RELEASE_NOTES-5.3.x.txt

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

Git Tag: 5.3-beta1-RC2
  https://github.com/apache/httpcomponents-core/tree/5.3-beta1-RC2

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.3-beta1-RC2
  revision 69812

Hashes:
  
28ca2a40a3df2346464517d67b06e701eaef99fc2f8354c9a57502572c80dae107085ac064bd7e0f253789935bbae8e730d9199070ddd31671afa69cb3b1520f
 httpcomponents-core-5.3-beta1-bin.tar.gz 
httpcomponents-core-5.3-beta1-bin.tar.gz
  
a2421a71a7cfccdeb949f26e9e37f335f9cb1e549f493bf95a0008551d54baa04e3008fc953eacf205c026483f54e312db7049de0a9ce1fc7d9d18ad20ddd689
 httpcomponents-core-5.3-beta1-src.zip httpcomponents-core-5.3-beta1-src.zip
  
94239d225edfe884b374249aaa6071dc01adec621a912c3aed8bafc93937c7684d2b502c91a1d40cd467812207be62571875b5c775a15779b5963c18b3ede38a
 httpcomponents-core-5.3-beta1-bin.zip httpcomponents-core-5.3-beta1-bin.zip
  
92e867876170c1db109d183d9b319e6490fe20e53f92f952500afa602e2ae796ecc2de7246a42d62cfb4606060264247f5ace9da463e19f2e581b664722b82ae
 httpcomponents-core-5.3-beta1-src.tar.gz 
httpcomponents-core-5.3-beta1-src.tar.gz

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


+1


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

Re: [VOTE] Release HttpCore 5.3-beta1 based on RC1

[Michael Osipov]

Am 2024-06-14 um 20:09 schrieb Oleg Kalnichevski:

[VOTE] Release HttpCore 5.3-beta1 based on RC1

Please vote on releasing these packages as HttpCore 5.3-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/httpcore-5.3-beta1-RC1/RELEASE_NOTES-5.3.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.3-beta1-RC1
  revision 69745

Hashes:
  
f49e8a52c1026a681669c0b110c6ee22f4e0f81bef02ba4dc369cd41cb7fcec627947d3083cae9c23437bf1494ba1789598b288b7adb2a4d4792f6f4b91d83e6
 httpcomponents-core-5.3-beta1-bin.tar.gz 
httpcomponents-core-5.3-beta1-bin.tar.gz
  
09170b2b46c9bd4ddfbcecfa8a172d28b99605d86b6ec0dea6e64b4d3a7e4b992cb517647e83095a54c0e2691f39aac4bebed742903008f895c3b2491de1aca4
 httpcomponents-core-5.3-beta1-src.zip httpcomponents-core-5.3-beta1-src.zip
  
eb66d2e4f846f8d1e3cc399bbfa07015a5416373e310f09bd88378134826cbd425e5f72df4ce7b3cd87e3fa7de55c0dbccae93ac501013dde388de5617df54cb
 httpcomponents-core-5.3-beta1-bin.zip httpcomponents-core-5.3-beta1-bin.zip
  
598bb3bbb4109a79cd8380cc82892d887ee8a464bcca428f9da70889fbd9ae0b445568ef660c4a751dd5d63bc5fdddaef8f146c79a62fa42acc4bbbd963df5da
 httpcomponents-core-5.3-beta1-src.tar.gz 
httpcomponents-core-5.3-beta1-src.tar.gz

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



+1


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

Re: HttpCore 5.3 / HttpClient 5.4 GA soon?

[Michael Osipov]

Am 2024-05-16 um 15:43 schrieb Oleg Kalnichevski:

Folks

I do not think there is any good reason to delay the GA release of
HttpCore 5.3 / HttpClient 5.4. There has been no feedback on the latest
API changes so far and I see no point waiting any longer.

I propose HttpCore 5.3 GA and HttpClient 5.4 GA be released soon.


Please go on.


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

[jira] [Commented] (HTTPCLIENT-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2325:


not for me, all parts have enough metadata to be selfsustained. I consider the 
behavior or {{text/*}} with out charset just undefined except the type has 
implicit semantics.

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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] [Comment Edited] (HTTPCLIENT-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2325 at 3/18/24 10:17 AM:
--

[~olegk], I do not agree with that. The request content type header has no 
influence on the part content type, they are completely disjoint. What makes 
you think that?


was (Author: michael-o):
[~olegk], I do not agree with that. The request content type header has on 
influence on the part content type, they are completely disjoint. What makes 
you think that?

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2325:


[~vladimirsitnikov], I agree with you that it makes no sense, but shouldn't 
cause any harm and should be just ignored. So even if it sent and a server 
chokes it is a bug. Please raise a PR for that, as said by Oleg.

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2325:


[~olegk], I do not agree with that. The request content type header has on 
influence on the part content type, they are completely disjoint. What makes 
you think that?

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2325:


This is the same as with {{application/json}}, peers can ignore undefined 
parameters. I don't understand why IIS is trying to process it especially 
because it does not have any semantic meaning to the content type...

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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] [Comment Edited] (HTTPCLIENT-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2325 at 3/18/24 8:26 AM:
-

I consider this as a duplicate/part of HTTPCLIENT-2159. I think this needs to 
be solved with a boolean flag for implicit or explicit character encodings.


was (Author: michael-o):
I consider this as a duplicate of HTTPCLIENT-2159. I think this needs to be 
solved with a boolean flag for implicit or explicit character encodings.

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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-2325) Avoid adding "; charset=" for multipart/form-data requests

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2325:


I consider this as a duplicate of HTTPCLIENT-2159. I think this needs to be 
solved with a boolean flag for implicit or explicit character encodings.

> Avoid adding "; charset=" for multipart/form-data requests
> --
>
> Key: HTTPCLIENT-2325
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2325
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.14
>Reporter: Vladimir Sitnikov
>Priority: Major
>
> Currently, HttpClient adds {{; charset=}} to {{multipart/form-data}} which 
> both
> 1) Breaks certain HTTP servers: see 
> https://github.com/apache/jmeter/pull/6251, 
> https://github.com/akka/akka-http/issues/338
> 2) Does not follow RFC 2046 and RFC 7578
> Even though including "charset" parameter is not explicitly forbidden by 
> RFCs, there are known HTTP servers that can't parse such requests, so why 
> generating the "charset=..." for multipart/form-data in the first place?
> See how RFC 7578 suggests setting the default charset: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-5.1.2
> They mention a {{_charset_}} field instead.
> 
> Unfortunately, removal of {{multipartEntityBuilder.setCharset(charset);}} in 
> the caller's code is not enough as HttpClient uses the supplied charset in 
> {{HttpBrowserCompatibleMultipart}}.
> ---
> I suggest to avoid sending {{charset}} within {{multipart/form-data}} header, 
> so it includes only {{boundary}} just like RFC 7578 samples.
> In other words, I suggest removing these lines: 
> https://github.com/apache/httpcomponents-client/blob/54900db4653d7f207477e6ee40135b88e9bcf832/httpmime/src/main/java/org/apache/http/entity/mime/MultipartEntityBuilder.java#L215-L217



--
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

Re: Development plans beyond HC 5.4

[Michael Osipov]

Am 2024-03-11 um 15:11 schrieb Oleg Kalnichevski:

HttpClient 5.4 is going to be the most feature rich minor release
probably since 4.3. There are plenty of small and not so small features
and improvements in it. Overall it is going to be a great release.

It will likely take a few more months to stablize it but somethime
around mid Summer we should be able to release the first GA. That is
the plan.

However beyond 5.4 our development plans are unclear. We can settle for
no particular plan and simply react to feature requests from our users
or we could invest some efforts and time proactively. Both approaches
are perfectly valid given the scarcity of project resources.

If we choose a more proactive stance there are several potential
features we could work on


core:

* Better / more efficient implementation of channel (socket) timeout
handling in the async i/o reactor. What we currently have is quite bad
for a large number of concurrent sessions

* CONNECT method support and connection tunneling for HTTP/2


* HTTP/2 for the classic transport (now with introduction of virtual
threads (fibers) in Java 21 we could revisit the issue of the classic
i/o model not working well for multiplexing protocols and try to solve
the problem by utilizing two fibers per HTTP/2 data stream)


* JRE level upgrade


client:

* Multipart entity support for the async transport

* Transparent content compression / decompression for the async
transport

* Query timeout / request deadline support

* JRE level upgrade


The real 1'000'000 USD question for us as a project however what the
hell we are going to do about HTTP/3?

HTTP/3 and QUIC dwarfs everytihng we have done so far in terms of
complexity. Do we have resources to pull it off? Do we attempt to build
our own QUIC layer or do we wait until QUIC is supported and provided
by JRE? Is QUIC even in scope for us?

The subject of HTTP/3 support is so big that it probably deserves a
separate discussion.

What do you, guys, think? How shall we proceed?


Although Ryan pretty much said everything and well balanced, I'd like to 
add a few notes personally:
* The Java upgrade madness is only then justified if you can 
substantially benefit from compile time features, except virtual threads 
which require quite some programming effort. Let 5.x stay on Java 8.
* I would only stabilize the libraries until end of fall because a lot 
of changes have happened and they need to soak in everyhwere. A lot of 
people still use 4.x.
* We need to keep to stay realistic. Calling out for fancy features with 
a little amount of volunteers is just not honest. This regards h2 on 
classic, QUIC + h3. Not feasable at all at the moment if at all with 
Java 8. SunJSSE does not even have TLS 1.3 PHA.


Upshot: I prefer high quality stablity and consistency over a plethora 
of halfcooked features.


Michael

Re: [VOTE] Release HttpClient 5.4-alpha2 based on RC1

[Michael Osipov]

Am 2024-03-07 um 09:07 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.4-alpha2.
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.4-alpha2-RC1/RELEASE_NOTES-5.4.x.txt

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

Git Tag: 5.4-alpha2-RC1
  https://github.com/apache/httpcomponents-client/tree/5.4-alpha2-RC1

Packages:
  
https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.4-alpha2-RC1
  revision 67773

Hashes:
  
c9b30430a769317be2eff95de187033f9c251468e08ac4682e5ea2e5d57d35288fae9fdb8a65e429e930e0bd127283587a0ce7ca8ffb3d3138342a19e7926b91
 httpcomponents-client-5.4-alpha2-src.tar.gz 
httpcomponents-client-5.4-alpha2-src.tar.gz
  
4bee83bcf13d6556b46f3f1f5a7758a3f222ceea616befd40a63f0617ef38b83deae9daf4cf166d318633446c1bb9acead3356e8fae15d8d7347df769b8f4eef
 httpcomponents-client-5.4-alpha2-bin.tar.gz 
httpcomponents-client-5.4-alpha2-bin.tar.gz
  
5ab76a138635291afa86b8204554df74f89f558499b87c8880f5c561019f5700e2af7ab39e6bffc6407bc7cd0ec17620e9fc62a184b1087a3b9e9e15771fa1e7
 httpcomponents-client-5.4-alpha2-bin.zip 
httpcomponents-client-5.4-alpha2-bin.zip
  
659e49b1833a18c9a88e93c948e323d7b81b62f7577b57caf25a667feaceabf202d81a6f0e5e1178c7c1399ead24cffa49d4795197f66fd5a3fb9a06b9d84351
 httpcomponents-client-5.4-alpha2-src.zip 
httpcomponents-client-5.4-alpha2-src.zip

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


+1


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

[jira] [Commented] (HTTPCLIENT-2323) When using HttpClientBuilder without setting a user agent an expensive operation seems to be used

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2323:


[~olegk], I have seen this scheme over and over again, many people don't 
understand that the client is stateful and expensive...

> When using HttpClientBuilder without setting a user agent an expensive 
> operation seems to be used
> -
>
> Key: HTTPCLIENT-2323
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2323
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.12
> Environment: Docker image using maven:3.9.1-eclipse-temurin-17-focal 
> running in kubernetes
>Reporter: Rob
>Priority: Minor
> Attachments: Screenshot 2024-02-28 at 12.51.41 PM.png
>
>
> We have an application that has a fairly high outbound http call rate using 
> Apache Http Client. We have been profiling it recently using the async 
> profiler and I noticed that almost 10% of our cpu time is spent in 
> VersionInfo.getUserAgent.
> We use HttpClientBuilder for each call (this seems the correct way to be able 
> to use different connection pools and settings).
> I am guessing because we do not explicitly set the user agent that the client 
> will go determine the client version and java version and use this... the 
> automatically generated user agent in our case looks like:
> {code:java}
> User-Agent: Apache-HttpClient/4.5.12 (Java/17.0.7){code}
> I have attached the profiler flame graph. I would imagine something like this 
> could be checked once and used for any further calls. I have not tested it 
> yet but I am hoping a workaround would be to make sure to set a user agent 
> and then none of this classloader stuff would need to happen for each call.



--
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-2323) When using HttpClientBuilder without setting a user agent an expensive operation seems to be used

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2323:


I bet the problem exists in 5 as well.

> When using HttpClientBuilder without setting a user agent an expensive 
> operation seems to be used
> -
>
> Key: HTTPCLIENT-2323
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2323
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.5.12
> Environment: Docker image using maven:3.9.1-eclipse-temurin-17-focal 
> running in kubernetes
>Reporter: Rob
>Priority: Minor
> Attachments: Screenshot 2024-02-28 at 12.51.41 PM.png
>
>
> We have an application that has a fairly high outbound http call rate using 
> Apache Http Client. We have been profiling it recently using the async 
> profiler and I noticed that almost 10% of our cpu time is spent in 
> VersionInfo.getUserAgent.
> We use HttpClientBuilder for each call (this seems the correct way to be able 
> to use different connection pools and settings).
> I am guessing because we do not explicitly set the user agent that the client 
> will go determine the client version and java version and use this... the 
> automatically generated user agent in our case looks like:
> {code:java}
> User-Agent: Apache-HttpClient/4.5.12 (Java/17.0.7){code}
> I have attached the profiler flame graph. I would imagine something like this 
> could be checked once and used for any further calls. I have not tested it 
> yet but I am hoping a workaround would be to make sure to set a user agent 
> and then none of this classloader stuff would need to happen for each call.



--
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] [Comment Edited] (HTTPCLIENT-2322) Javadoc lists each class twice

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2322 at 2/28/24 4:32 PM:
-

This is a bug in Maven Javadoc Plugin, more precisely a regression from a fix. 
Need to recall from memory which JIRA issue. It is documented.


was (Author: michael-o):
This is a bug bug in Maven Javadoc Plugin, more precisely a regression from a 
fix. Need to recall from memory which JIRA issue. It is documented.

> Javadoc lists each class twice
> --
>
> Key: HTTPCLIENT-2322
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2322
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Konrad Windszus
>Priority: Minor
>
> The classes overview at 
> https://hc.apache.org/httpcomponents-client-5.3.x/current/httpclient5/apidocs/allclasses-frame.html
>  lists each class twice.



--
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-2322) Javadoc lists each class twice

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2322:


This is a bug bug in Maven Javadoc Plugin, more precisely a regression from a 
fix. Need to recall from memory which JIRA issue. It is documented.

> Javadoc lists each class twice
> --
>
> Key: HTTPCLIENT-2322
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2322
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Konrad Windszus
>Priority: Minor
>
> The classes overview at 
> https://hc.apache.org/httpcomponents-client-5.3.x/current/httpclient5/apidocs/allclasses-frame.html
>  lists each class twice.



--
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] [Updated] (HTTPCLIENT-2318) Implement HttpClientConnectionManager#isShutdown

[Michael Osipov (Jira)]

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

Michael Osipov updated HTTPCLIENT-2318:
---
Fix Version/s: (was: 4.5.15)
   (was: 5.3.2)

> Implement HttpClientConnectionManager#isShutdown
> 
>
> Key: HTTPCLIENT-2318
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2318
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Edmund Ham
>Priority: Major
>
> Hi all,
> We have an internal library that has core logics and lots of microservices 
> are using it. Within the internal library, we have "HttpClientPool" where we 
> are caching different HttpClient based on keys and microservices are using 
> them. Recently, we've been seeing some of OOM errors on microservices when 
> using HttpClients from our "HttpClientPool".
> From https://issues.apache.org/jira/browse/HTTPCLIENT-2039 and 
> https://issues.apache.org/jira/browse/HTTPCLIENT-1924 we understand that it 
> is the intention to shutdown the connection pool in case of Java Errors. I'm 
> now wondering if it's possible to have new API, 
> "HttpClientConnectionManager#isShutdown" so that we as a library can identify 
> if the connection pool is closed or not, before giving out to our clients?
> Currently there seems to be no way to identify it, unless we actually try to 
> make an outbound call and get "IllegalStateException: Connection pool shut 
> down" exception message, which makes impossible for us to do because we as a 
> library don't want to make additional HTTP client call every time when our 
> client requests for the HttpClient instance.
> Thanks!



--
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

Re: [VOTE] Release HttpCore 5.3-alpha2 based on RC1

[Michael Osipov]

Am 2024-02-10 um 15:36 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.3-alpha2.
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.3-alpha2-RC1/RELEASE_NOTES-5.3.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.3-alpha2-RC1
  revision 67275

Hashes:
  
537391b7090bb1fdbb3412e45c2b1a8e18f2d387c747b7d916bf69e533c84c2b358bd030b8cdcaca96cde134f04ad84049c921ecc34d1d2ff89164c80d31bc35
 httpcomponents-core-5.3-alpha2-bin.zip httpcomponents-core-5.3-alpha2-bin.zip
  
f415918fdd94fa637eeb315f6677d95407e2c41608edc76eaabb32e037f05c118677bcabb252d7495c010a64d7be3329f238f3601ca3f84967c931c6ba4cde38
 httpcomponents-core-5.3-alpha2-src.tar.gz 
httpcomponents-core-5.3-alpha2-src.tar.gz
  
05f96bda633ddbd40c99bf68671b72c79acc383e8e4ddf4c2d0567da8de2bbd2de0fb3de2d5a5a9b97612b6b6afc62fa9a3ea573090f51096e2490b756646136
 httpcomponents-core-5.3-alpha2-src.zip httpcomponents-core-5.3-alpha2-src.zip
  
a7b1496be7fc98635bb4a541aa8704f8dc9da13f3517bf85a41166529ee2134e44046df70f4b00d312d5da373921e4ed394ed2ad5377c2ef86da68320284feab
 httpcomponents-core-5.3-alpha2-bin.tar.gz 
httpcomponents-core-5.3-alpha2-bin.tar.gz

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



+1


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

[jira] [Commented] (HTTPCLIENT-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


{{LICENSE}} with AL2.0 and MIT would make sense if we'd have dual-licensed 
code, but we don't. I wouldn't touch packaged license file.

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


Adding [~hboutemy] to the mix...

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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] [Comment Edited] (HTTPCLIENT-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2317 at 2/6/24 2:13 PM:


With:
{noformat}
osipovmi@deblndw011x:~/var/Projekte/httpcomponents-client/httpclient5 (master 
*=)
$ git diff -U0
diff --git a/httpclient5/pom.xml b/httpclient5/pom.xml
index 57a5c0c32..bfe2e9cae 100644
--- a/httpclient5/pom.xml
+++ b/httpclient5/pom.xml
@@ -59,0 +60,6 @@
+
+  pl.droidsonroids.gradle
+  publicsuffix
+  1.0.0
+  pom
+
{noformat}

{{META-INF/DEPENDENCIES}} is properly populated:
{noformat}
// --
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// --

Apache HttpClient


From: 'an unknown organization'
  - org.brotli:dec (http://brotli.org/dec) org.brotli:dec:jar:0.1.2
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)
  - org.conscrypt:conscrypt-openjdk-uber (https://conscrypt.org/) 
org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2
License: Apache 2  (https://www.apache.org/licenses/LICENSE-2.0)
  - Public Suffix List (https://publicsuffix.org/) 
pl.droidsonroids.gradle:publicsuffix:pom:1.0.0
License: MPL-2.0  (https://mozilla.org/MPL/2.0/)

From: 'QOS.ch' (http://www.qos.ch)
  - SLF4J API Module (http://www.slf4j.org) org.slf4j:slf4j-api:jar:1.7.36
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)

From: 'The Apache Software Foundation' (https://www.apache.org/)
  - Apache HttpComponents Core HTTP/1.1 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5/) 
org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
  - Apache HttpComponents Core HTTP/2 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5-h2/) 
org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
{noformat}

[~jlahoda], is that sufficient?


was (Author: michael-o):
With:
{noformat}
osipovmi@deblndw011x:~/var/Projekte/httpcomponents-client/httpclient5 (master 
*=)
$ git diff -U0
diff --git a/httpclient5/pom.xml b/httpclient5/pom.xml
index 57a5c0c32..bfe2e9cae 100644
--- a/httpclient5/pom.xml
+++ b/httpclient5/pom.xml
@@ -59,0 +60,6 @@
+
+  pl.droidsonroids.gradle
+  publicsuffix
+  1.0.0
+  pom
+
{noformat}

{{META-INF/DEPENDENCIES}} is properly populated:
{noformat}
// --
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// --

Apache HttpClient


From: 'an unknown organization'
  - org.brotli:dec (http://brotli.org/dec) org.brotli:dec:jar:0.1.2
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)
  - org.conscrypt:conscrypt-openjdk-uber (https://conscrypt.org/) 
org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2
License: Apache 2  (https://www.apache.org/licenses/LICENSE-2.0)
  - Public Suffix List (https://publicsuffix.org/) 
pl.droidsonroids.gradle:publicsuffix:pom:1.0.0
License: MPL-2.0  (https://mozilla.org/MPL/2.0/)

From: 'QOS.ch' (http://www.qos.ch)
  - SLF4J API Module (http://www.slf4j.org) org.slf4j:slf4j-api:jar:1.7.36
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)

From: 'The Apache Software Foundation' (https://www.apache.org/)
  - Apache HttpComponents Core HTTP/1.1 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5/) 
org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
  - Apache HttpComponents Core HTTP/2 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5-h2/) 
org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
{noformat}


> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclie

[jira] [Commented] (HTTPCLIENT-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


With:
{code:patch}
osipovmi@deblndw011x:~/var/Projekte/httpcomponents-client/httpclient5 (master 
*=)
$ git diff -U0
diff --git a/httpclient5/pom.xml b/httpclient5/pom.xml
index 57a5c0c32..bfe2e9cae 100644
--- a/httpclient5/pom.xml
+++ b/httpclient5/pom.xml
@@ -59,0 +60,6 @@
+
+  pl.droidsonroids.gradle
+  publicsuffix
+  1.0.0
+  pom
+
{code}

{{META-INF/DEPENDENCIES}} is properly populated:
{noformat}
// --
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// --

Apache HttpClient


From: 'an unknown organization'
  - org.brotli:dec (http://brotli.org/dec) org.brotli:dec:jar:0.1.2
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)
  - org.conscrypt:conscrypt-openjdk-uber (https://conscrypt.org/) 
org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2
License: Apache 2  (https://www.apache.org/licenses/LICENSE-2.0)
  - Public Suffix List (https://publicsuffix.org/) 
pl.droidsonroids.gradle:publicsuffix:pom:1.0.0
License: MPL-2.0  (https://mozilla.org/MPL/2.0/)

From: 'QOS.ch' (http://www.qos.ch)
  - SLF4J API Module (http://www.slf4j.org) org.slf4j:slf4j-api:jar:1.7.36
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)

From: 'The Apache Software Foundation' (https://www.apache.org/)
  - Apache HttpComponents Core HTTP/1.1 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5/) 
org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
  - Apache HttpComponents Core HTTP/2 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5-h2/) 
org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
{noformat}


> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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] [Comment Edited] (HTTPCLIENT-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2317 at 2/6/24 2:12 PM:


With:
{noformat}
osipovmi@deblndw011x:~/var/Projekte/httpcomponents-client/httpclient5 (master 
*=)
$ git diff -U0
diff --git a/httpclient5/pom.xml b/httpclient5/pom.xml
index 57a5c0c32..bfe2e9cae 100644
--- a/httpclient5/pom.xml
+++ b/httpclient5/pom.xml
@@ -59,0 +60,6 @@
+
+  pl.droidsonroids.gradle
+  publicsuffix
+  1.0.0
+  pom
+
{noformat}

{{META-INF/DEPENDENCIES}} is properly populated:
{noformat}
// --
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// --

Apache HttpClient


From: 'an unknown organization'
  - org.brotli:dec (http://brotli.org/dec) org.brotli:dec:jar:0.1.2
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)
  - org.conscrypt:conscrypt-openjdk-uber (https://conscrypt.org/) 
org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2
License: Apache 2  (https://www.apache.org/licenses/LICENSE-2.0)
  - Public Suffix List (https://publicsuffix.org/) 
pl.droidsonroids.gradle:publicsuffix:pom:1.0.0
License: MPL-2.0  (https://mozilla.org/MPL/2.0/)

From: 'QOS.ch' (http://www.qos.ch)
  - SLF4J API Module (http://www.slf4j.org) org.slf4j:slf4j-api:jar:1.7.36
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)

From: 'The Apache Software Foundation' (https://www.apache.org/)
  - Apache HttpComponents Core HTTP/1.1 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5/) 
org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
  - Apache HttpComponents Core HTTP/2 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5-h2/) 
org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
{noformat}



was (Author: michael-o):
With:
{code:patch}
osipovmi@deblndw011x:~/var/Projekte/httpcomponents-client/httpclient5 (master 
*=)
$ git diff -U0
diff --git a/httpclient5/pom.xml b/httpclient5/pom.xml
index 57a5c0c32..bfe2e9cae 100644
--- a/httpclient5/pom.xml
+++ b/httpclient5/pom.xml
@@ -59,0 +60,6 @@
+
+  pl.droidsonroids.gradle
+  publicsuffix
+  1.0.0
+  pom
+
{code}

{{META-INF/DEPENDENCIES}} is properly populated:
{noformat}
// --
// Transitive dependencies of this project determined from the
// maven pom organized by organization.
// --

Apache HttpClient


From: 'an unknown organization'
  - org.brotli:dec (http://brotli.org/dec) org.brotli:dec:jar:0.1.2
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)
  - org.conscrypt:conscrypt-openjdk-uber (https://conscrypt.org/) 
org.conscrypt:conscrypt-openjdk-uber:jar:2.5.2
License: Apache 2  (https://www.apache.org/licenses/LICENSE-2.0)
  - Public Suffix List (https://publicsuffix.org/) 
pl.droidsonroids.gradle:publicsuffix:pom:1.0.0
License: MPL-2.0  (https://mozilla.org/MPL/2.0/)

From: 'QOS.ch' (http://www.qos.ch)
  - SLF4J API Module (http://www.slf4j.org) org.slf4j:slf4j-api:jar:1.7.36
License: MIT License  (http://www.opensource.org/licenses/mit-license.php)

From: 'The Apache Software Foundation' (https://www.apache.org/)
  - Apache HttpComponents Core HTTP/1.1 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5/) 
org.apache.httpcomponents.core5:httpcore5:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
  - Apache HttpComponents Core HTTP/2 
(https://hc.apache.org/httpcomponents-core-5.3.x/5.3-alpha1/httpcore5-h2/) 
org.apache.httpcomponents.core5:httpcore5-h2:jar:5.3-alpha1
License: Apache License, Version 2.0  
(https://www.apache.org/licenses/LICENSE-2.0.txt)
{noformat}


> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, lik

[jira] [Commented] (HTTPCLIENT-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


Easiest one we can depend on 
https://search.maven.org/artifact/pl.droidsonroids.gradle/publicsuffix/1.0.0/pom
 and https://github.com/DroidsOnRoids/public-suffix-mpl. License should be 
there then while the actual PSL we still need to include. Sounds better than 
overriding apache parent.

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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] [Comment Edited] (HTTPCLIENT-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2317 at 2/6/24 1:00 PM:


Our license file fromes from 
https://repo1.maven.org/maven2/org/apache/apache/resources/apache-jar-resource-bundle/1.5/
 and here https://repo1.maven.org/maven2/org/apache/apache/31/apache-31.pom, 
remote resources plugin. Since PSL is not a Maven artifact, it does not appear 
there.


was (Author: michael-o):
Our license file fromes from 
https://repo1.maven.org/maven2/org/apache/apache/resources/apache-jar-resource-bundle/1.5/
 and here https://repo1.maven.org/maven2/org/apache/apache/31/apache-31.pom, 
remote resources plugin.

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


Our license file fromes from 
https://repo1.maven.org/maven2/org/apache/apache/resources/apache-jar-resource-bundle/1.5/
 and here https://repo1.maven.org/maven2/org/apache/apache/31/apache-31.pom, 
remote resources plugin.

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 4.5.14, 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


Such issues with the license was the reason why we dropped JSoup from the 
delivery.

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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-2317) The license in the httpclient5 artifact on Maven central is not correct.

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2317:


I believe  that {{LICENSE}} should only contain our license and they are 
supplementary files required for such cases.

> The license in the httpclient5 artifact on Maven central is not correct.
> 
>
> Key: HTTPCLIENT-2317
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2317
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Affects Versions: 5.3.1, 5.4-alpha1
>Reporter: Jan Lahoda
>Priority: Minor
>
> Looking at the 'httpclient5' artifact on Maven central, like:
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.3.1/httpclient5-5.3.1.jar]
> [https://repo1.maven.org/maven2/org/apache/httpcomponents/client5/httpclient5/5.4-alpha1/httpclient5-5.4-alpha1.jar]
> these contain 'mozilla/public-suffix-list.txt', which is under MPL 2.0, but 
> the license file embedded in these artifacts (META-INF/LICENSE) does not 
> contain the MPL 2.0.
>  
> The binary file downloadable from Apache download server has the correct 
> license file:
> [https://dlcdn.apache.org//httpcomponents/httpclient/binary/httpcomponents-client-5.3.1-bin.tar.gz]
>  
> It would be nice if the artifacts on Maven central could have the correct 
> content of the license file.



--
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

Re: [VOTE] Release HttpClient 5.3.1 based on RC1

[Michael Osipov]

Am 2024-01-21 um 11:03 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.3.1.
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.3.1-RC1/RELEASE_NOTES-5.3.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.3.1-RC1
  revision 66728

Hashes:
  
5f7b2fe19275c5ed78f3a3874e6fb43fb0acdd17311c90c78f4cf29c51ab67ddc0fd6737dddb2487ec1a2a2304d1cdda11f7f100fc8a763ca101e19c155658f4
 httpcomponents-client-5.3.1-src.zip httpcomponents-client-5.3.1-src.zip
  
f6ead1504fd963923c0741c3c234b1febe51a4cf146ed794d8d6e9a51e251bc7280cf1209d236991ecb545066549da6186a08bca6c7ac74cdfd78c534ff404f7
 httpcomponents-client-5.3.1-bin.tar.gz httpcomponents-client-5.3.1-bin.tar.gz
  
271a9e346c0f2b3861eb6f0ace83ba082be338495a5d620607200f84bc42acb47cf68f50ab12b9d4e0438e3b5b87bed4c21cda03a4fec5fcb9359886ebb7f4b0
 httpcomponents-client-5.3.1-src.tar.gz httpcomponents-client-5.3.1-src.tar.gz
  
3cc0d8dde15402137c7665662f3b63efa977b13121534499a264b57e3b45b0eee3117b53fb028a9659caaf111e5aa7bd3f62c8f3984fbd98bb6f02d42da1f2bc
 httpcomponents-client-5.3.1-bin.zip httpcomponents-client-5.3.1-bin.zip

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


+1


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

[jira] [Commented] (HTTPCLIENT-2159) Invalid handling of charset content type parameter

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2159:


[~olegk], no both are unrelated and this one is still fully valid.

> Invalid handling of charset content type parameter
> --
>
> Key: HTTPCLIENT-2159
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2159
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>    Reporter: Michael Osipov
>Priority: Major
>
> Based on [~reschke]'s, 
> [comment|https://issues.apache.org/jira/browse/HTTPCLIENT-2144?focusedCommentId=17310053&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17310053].
>  We are treating several content types incorrectly. We have in 
> {{org.apache.hc.core5.http.ContentType}} several content types defined which 
> are per definition UTF-8 and do not contain any {{charset}} parameter or have 
> another form transport encoding. Affected are:
> {code}
> public static final ContentType APPLICATION_FORM_URLENCODED = create(
> "application/x-www-form-urlencoded", StandardCharsets.ISO_8859_1);
> public static final ContentType APPLICATION_JSON = create(
> "application/json", StandardCharsets.UTF_8);
> public static final ContentType APPLICATION_NDJSON = create(
> "application/x-ndjson", StandardCharsets.UTF_8);
> public static final ContentType APPLICATION_PDF = create(
> "application/pdf", StandardCharsets.UTF_8);
> public static final ContentType APPLICATION_PROBLEM_JSON = create(
> "application/problem+json", StandardCharsets.UTF_8);
> public static final ContentType MULTIPART_FORM_DATA = create(
> "multipart/form-data", StandardCharsets.ISO_8859_1);
> public static final ContentType MULTIPART_MIXED = create(
> "multipart/mixed", StandardCharsets.ISO_8859_1);
> public static final ContentType MULTIPART_RELATED = create(
> "multipart/related", StandardCharsets.ISO_8859_1);
> public static final ContentType TEXT_HTML = create(
> "text/html", StandardCharsets.ISO_8859_1);
> public static final ContentType TEXT_EVENT_STREAM = create(
> "text/event-stream", StandardCharsets.UTF_8);
> {code}
> * {{application/x-www-form-urlencoded}}: Does not have a charset parameter: 
> https://www.iana.org/assignments/media-types/application/x-www-form-urlencoded.
>  HTML5 defines https://url.spec.whatwg.org/#urlencoded-serializing how to 
> apply alternative encoding, but UTF-8 is standard.
> * {{application/json}}, {{application/x-ndjson}}, 
> {{application/problem+json}}: There is no charset definition because JSON is 
> *always* UTF-8. The charset paremeter has no meaning: 
> https://datatracker.ietf.org/doc/html/rfc8259#section-11
> * {{application/pdf}}: This is binary encoding, no charset
> * {{text/event-stream}}: Defined *always* as UTF-8: 
> https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events-intro
> * {{text/html}}: https://html.spec.whatwg.org/ does not define ISO-8859-1 to 
> be the default encoding. it says that encoding must be supplied by some means 
> and an algorithm is applied to find it. It seems that UTF-8 is expected these 
> days.
> * {{multipart/mixed}}: Does not have a charset parameter, it is up to the 
> parts to supply proper encoding to perform byte-to-char conversion: 
> https://datatracker.ietf.org/doc/html/rfc2046
> * {{multipart/related}}: Does not have a charset parameter, it is up to the 
> parts to supply proper encoding to perform byte-to-char conversion: 
> https://datatracker.ietf.org/doc/html/rfc2387
> * {{multipart/form-data}}: Does not have a charset parameter, the RFC defines 
> a {{_charset_}} form field for that: 
> https://datatracker.ietf.org/doc/html/rfc7578#section-4.6
> {{charset}} applies to the transport layer only and never to the semantics of 
> the content-type. E.g., {{application/x-www-form-urlencoded}}.



--
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

Re: [VOTE] Release HttpClient 5.4-alpha1 based on RC1

[Michael Osipov]

Am 2023-12-26 um 15:42 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.4-alpha1.
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.4-alpha1-RC1/RELEASE_NOTES-5.4.x.txt

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

Git Tag: 5.4-alpha1-RC1
  https://github.com/apache/httpcomponents-client/tree/5.4-alpha1-RC1

Packages:
  
https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.4-alpha1-RC1
  revision 66330

Hashes:
  
c5baf8680839872a8ef713b293ec98cdcaa11d5ccb14feabfbdfe3ca071a26005d43b77e711c7f62c6dca4c8291641bdd92219e164c2d8cc48e86b943f723bdc
 httpcomponents-client-5.4-alpha1-src.tar.gz 
httpcomponents-client-5.4-alpha1-src.tar.gz
  
d2de667a028ffbaaa5019fcae91126d032f21c563d633458c867fe0948d04acba40e2c07b7d5a3ed41b42c48526974a4a3bba0dfe4b9544b89864aa54c62b3de
 httpcomponents-client-5.4-alpha1-bin.zip 
httpcomponents-client-5.4-alpha1-bin.zip
  
17b7ee5d3cba3be05cefe8ccfcba73671db3e2be8b92c1a53a84e61ae554c9730d20f4bbe734b2b1d27cc522278761d926b8ba34760adb2928144984f3bcb910
 httpcomponents-client-5.4-alpha1-src.zip 
httpcomponents-client-5.4-alpha1-src.zip
  
e6f77e7d80f14f22086daae7369e2e4e4ce9cc9a6d44f2000d34206f3849fe9bc89c1741c7845cf6b80bc3a60a61eb9fd91104a22f3fd2eda604956a5bee3894
 httpcomponents-client-5.4-alpha1-bin.tar.gz 
httpcomponents-client-5.4-alpha1-bin.tar.gz

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


+1


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

Re: [VOTE] Release HttpCore 5.3-alpha1 based on RC2

[Michael Osipov]

Am 2023-12-20 um 19:01 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.3-alpha1.
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.3-alpha1-RC2/RELEASE_NOTES-5.3.x.txt

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

Git Tag: 5.3-alpha1-RC2
  https://github.com/apache/httpcomponents-core/tree/5.3-alpha1-RC2

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.3-alpha1-RC2
  revision 66226

Hashes:
  
9b903277106fba68ab152819ca61f0407426e2d5706077229a0a205db3af0d03b413d95cc205f6a350055fc8f8924f0a66d6617ae9b1a098c5e9b6bb8cd55388
 httpcomponents-core-5.3-alpha1-src.zip httpcomponents-core-5.3-alpha1-src.zip
  
63accf683387c0c466448e83cdfaddf72014ca47d0b06814256d2db1b5615a0eb474d5fbd0175ebc9286c58fa83d13cab9becb202786a72cce32323f9e6f1935
 httpcomponents-core-5.3-alpha1-bin.tar.gz 
httpcomponents-core-5.3-alpha1-bin.tar.gz
  
11250737403a5fd4a9a0fe7b3a84355f1eac77446730d73d8e031bc3c6412ab36e9c2fa82527273c017b48ac5c8650a673197dd6d19fffeb0024f3a92e2a450d
 httpcomponents-core-5.3-alpha1-bin.zip httpcomponents-core-5.3-alpha1-bin.zip
  
a493b0f3c9419c32a36a2e6fd57d3bc6aaa3ad0b6bfe022f062ae140995ec9a4850668c90407c20547a1ed49fd3ff62a76b5da5fd86d8f90e913390ab3672274
 httpcomponents-core-5.3-alpha1-src.tar.gz 
httpcomponents-core-5.3-alpha1-src.tar.gz

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



+1


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

Re: [VOTE] Release HttpCore 5.3-alpha1 based on RC1

[Michael Osipov]

On 2023/12/15 13:38:36 Oleg Kalnichevski wrote:
> 
> Please vote on releasing these packages as HttpCore 5.3-alpha1.
> 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.3-alpha1-RC1/RELEASE_NOTES-5.3.x.txt
> 
> Maven artefacts:
>  
> https://repository.apache.org/content/repositories/orgapachehttpcomponents-1168/org/apache/httpcomponents/core5/
> 
> Git Tag: 5.3-alpha1-RC1
>  https://github.com/apache/httpcomponents-core/tree/5.3-alpha1-RC1
> 
> Packages:
>  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.3-alpha1-RC1
>  revision 66083
> 
> Hashes:
>  
> cadc7ce5632af5fdcf6dae385b676424f671ff6c156a9027ddfb641e7931e2a02b9de951273bb2d6b973022640186980795df8f95868762ed51738baab85ef33
>  httpcomponents-core-5.3-alpha1-src.zip httpcomponents-core-5.3-alpha1-src.zip
>  
> 0fea5033b25d75aa32ba2a830f70239d13df4b369ccecd5438889caf31e5a6a41849f1b3e777d9201e3e58b04617e1738346d3734d7d9fd7f7e694d94c3fb2aa
>  httpcomponents-core-5.3-alpha1-bin.tar.gz 
> httpcomponents-core-5.3-alpha1-bin.tar.gz
>  
> f85c75cafb6ca58f0df4dfd9f51d6d02a502dad2ad0f414c6c90656cea70079697f94923d8412cfe6222772ff7cf3f88c62e5197e0ca1537a533c286299f91c7
>  httpcomponents-core-5.3-alpha1-bin.zip httpcomponents-core-5.3-alpha1-bin.zip
>  
> e24368d1080e6827bfd553586375d09015e30fd68878bcb044b9ca8399933c145a3ffc29961a39ba9dcb1033aed7a9f022f0dcd1ed4bcfa9b98339e3412063e5
>  httpcomponents-core-5.3-alpha1-src.tar.gz 
> httpcomponents-core-5.3-alpha1-src.tar.gz
> 
> Keys:
>  https://www.apache.org/dist/httpcomponents/httpcore/KEYS
> 
> --
> Vote: HttpCore 5.3-alpha1 release
> [ ] +1 Release the packages as HttpCore 5.3-alpha1.
> [ ] -1 I am against releasing the packages (must include a reason).


+1

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

Re: [VOTE] HttpAsycClient 4.1 and HttpCore NIO 4.4 End of Life / End of Support

[Michael Osipov]

Am 2023-12-08 um 15:10 schrieb Oleg Kalnichevski:

Folks

I propose that as of this moment any support for HttpAsycClient 4.1 and 
HttpCore NIO 4.4 be discontinued and the remaining users of those 
libraries be strongly encouraged to upgrade to  HttpClient 5.3 and 
HttpCore 5.2.


This does not affect HttpClient 4.5 and HttpCore 4.4 (classic). Yet.


I wouldn't even use the word "supported" at all. At Maven we say 
"maintained", that's it. "Supported" has, unfortunately, a very 
formal/commercial connotation.


M

Re: [VOTE] Release HttpClient 5.3 based on RC1

[Michael Osipov]

Am 2023-12-03 um 10:42 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.3.
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.3-RC1/RELEASE_NOTES-5.3.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.3-RC1
  revision 65801

Hashes:
  
7fd185c541977aab6d909d0c1479d8aac50a1984fd9d5ecb2a9d46e6de508066286eb6a3ce310d3e25213a8c02100173b675aaa90d2062cb8709b04fb909b5fb
 httpcomponents-client-5.3-src.zip httpcomponents-client-5.3-src.zip
  
615fdd6dfe9dcca36a5f2d68d11b5c4a6a96d92a15913af16c873e9a56b4795072860300d279a29364475c4c0900aa5f658d0ef8a4f9bc93b942b83cf9c5513b
 httpcomponents-client-5.3-src.tar.gz httpcomponents-client-5.3-src.tar.gz
  
338ce8c7ffaa64289ff10c983a12d27eaf0af964bbbab5c7a191d0f85bbd2d64286e67b733cb6213add0ad390b6d0d76dd8c2a378ac4f8a86e4bc95463a952f7
 httpcomponents-client-5.3-bin.zip httpcomponents-client-5.3-bin.zip
  
4b5cc64d41df497c49bba5e9bce8dd4079a71c7a1bce93280b169599e205cdc25c100831ed0d299c093e25ab2e64877eae18cbc822d0ce34826b2a8dd8566538
 httpcomponents-client-5.3-bin.tar.gz httpcomponents-client-5.3-bin.tar.gz

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



+1


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

[jira] [Commented] (HTTPCORE-746) Deadlock with Java Virtual Threads

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-746:
-

Here is the difference: AWS makes billions with their shit, we make zero.

> Deadlock with Java Virtual Threads
> --
>
> Key: HTTPCORE-746
> URL: https://issues.apache.org/jira/browse/HTTPCORE-746
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 4.4.16
> Environment: openjdk version "20.0.1" 2023-04-18
> archlinux
>Reporter: marsqing
>Priority: Minor
>  Labels: volunteers-wanted
> Fix For: Stuck
>
> Attachments: LoomWithApacheHttpClientTest.java
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> [Virtual Threads|https://openjdk.org/jeps/444] is expected to be released in 
> JDK21 soon. Contrast to traditional 'platform threads', virtual threads will 
> usually unmount from platform threads when doing blocking operations. But 
> accoring to the doc above, when doing blocking operations in synchronized 
> block/method, the carrying platform thread will be pinned and can not carry 
> other virtual threads.
>  
> This limitation will make the sample in the attachment deadlocked. Because 
> all the platform threads add pinned in 
> [await|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#LL391C30-L391C30]
>  because it is in a  [synchronized 
> block|https://github.com/apache/httpcomponents-core/blob/45d8a4cb391f591bb8d380b820437b651435774f/httpcore/src/main/java/org/apache/http/pool/AbstractConnPool.java#L244]
>  and no connection is available in the pool. The only virtual thread which 
> can release the connection to the pool is waiting for some platform threads 
> to carry it. That is the platform thread is waiting for a connection while 
> the connection is waiting the platform thread to carry its virtual thread and 
> return the connection. Thus a deadlock.
>  
> If we replace the synchronized above with a ReentrantLock, no thead will be 
> pinned and no deadlock will occur. Accoring to the doc above, the limitation 
> may be removed in future JDK versions. But before that, we may need to 
> replace synchronized with some locks.  Do we have any related plan? Thanks!



--
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

Re: [VOTE] Release HttpClient 5.2.3 based on RC1

[Michael Osipov]

Am 2023-11-28 um 16:08 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.2.3.
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.3-RC1/RELEASE_NOTES-5.2.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.2.3-RC1
  revision 65627

Hashes:
  
ff4d25cfde77adc5cb625b2ec2dfde6dbcb89df919fff2c0787769d4da1d34838f6aef2d7db99c09b43ad22fbf4cea7486197f2b4191f749dcb328ed4a468a66
 httpcomponents-client-5.2.3-bin.zip httpcomponents-client-5.2.3-bin.zip
  
528c8fae0e7c9d10f5a24c635d21c2557b8d89fdad9ac3c618dccbfeea1938b9eaec09a8aae763e878092e97f2a8b0009151afc03e9ce6a4f38d914ec6db1fcb
 httpcomponents-client-5.2.3-src.tar.gz httpcomponents-client-5.2.3-src.tar.gz
  
61024c92f61e77253b3fb075cec29d644e70c26fcac6feba4e05af7eba104eaf94af09c5360f9420bc7451f88b47fa45863909af0e116fa1ce5a83bdf0249d2b
 httpcomponents-client-5.2.3-bin.tar.gz httpcomponents-client-5.2.3-bin.tar.gz
  
0fe39bbc07a62b390d76a6d2c27d507c89ca79409acb6b494221f84ded27d737cb5317485e1874ee0fbabb7a9c87b972d67988d1f6942b340420e0eeae12f8e2
 httpcomponents-client-5.2.3-src.zip httpcomponents-client-5.2.3-src.zip

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


+1


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

Re: HttpClient 5.2.3 release notes

[Michael Osipov]

LGTM

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

[Michael Osipov]

Am 2023-11-24 um 20:12 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.2.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.2.4-RC1/RELEASE_NOTES-5.2.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2.4-RC1
  revision 65526

Hashes:
  
352cbaa9325560006ca5d1dfb71b6f16cd3900afa56d31e894100c0615797750c15efbdc00cfdba9a173062fe7effcb77c54d628524db1304a905f332ceb9bf6
 httpcomponents-core-5.2.4-bin.tar.gz httpcomponents-core-5.2.4-bin.tar.gz
  
b069bce30ae14724d4aad21ab89d3bfab7e51d640ff35079991f3caa19ebcb99fbe95695c58bef6a716e2d2c30163a01df64f0d49be5e725381aba83c85e5837
 httpcomponents-core-5.2.4-src.zip httpcomponents-core-5.2.4-src.zip
  
f8fc29d29c4b890e27182025e1a44a3c7ba7d8459a9103cd712e93721b0adee4ca735357b5ac4f8d6323544a7e6d269a8ba613c580acf26cf20bc762cee14146
 httpcomponents-core-5.2.4-bin.zip httpcomponents-core-5.2.4-bin.zip
  
423cf2f26c5b27a5657fe52a878ae0d293873241c9248848d338505bc588a7197f64fc167a84880a4e4fddc28b9ac01b225cdf3dc4d2e3c4cc0c0b93b9855f1b
 httpcomponents-core-5.2.4-src.tar.gz httpcomponents-core-5.2.4-src.tar.gz

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



+1


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

[Michael Osipov]

Am 2023-11-19 um 10:02 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.2.2.
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.2-RC1/RELEASE_NOTES-5.2.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.2.2-RC1
  revision 65415

Hashes:
  
a1dc9c4f64addb6531ae0535647aa412dbdc476b8fd2d8a494c276c733461f7a485ae9e90f8289085dd50ae68692cc9f17e0b7e1a91331a07695a3de4c652981
 httpcomponents-client-5.2.2-src.zip httpcomponents-client-5.2.2-src.zip
  
10a0b8d4b83dfd623d722186865a281785b03c2c7a0fbe7f3784fd45d95c8f996dcafb3bac4297679ecaca32ac0b3f398edb50d43819def56b2dfe7dec3114fb
 httpcomponents-client-5.2.2-bin.tar.gz httpcomponents-client-5.2.2-bin.tar.gz
  
6aa51ab47c6a592829e40c66155332894d0712524ce9f9d82e395ac96689d75d6f8e9db957b5375bb6c571d6e087b4cb937bba40d04c7bdfd00c5a7fda9ba0ae
 httpcomponents-client-5.2.2-src.tar.gz httpcomponents-client-5.2.2-src.tar.gz
  
7042d79b80d57e9dc46b8cf9c4c7f2e1789da5881f127e44bbd1a42048dca55a8e3bf45909e6049fa65bf417dc0e0749dab0320414582b5832d2ad5a68700579
 httpcomponents-client-5.2.2-bin.zip httpcomponents-client-5.2.2-bin.zip

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



+1


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

Re: Development plans / releases in the coming weeks

[Michael Osipov]

Am 2023-11-17 um 10:04 schrieb Oleg Kalnichevski:

Folks

The core and client code bases should now be conformant with RFC 9110,
9111 and 9112.

I would be nice if some one could take upon themselves to review
HttpClient for conformance with RFC 7617 and 7616 and that would make
HttpClient conformant with the latest protocol specifications.

I would like to cut several releases in the coming weeks:

1. HttpClient 5.2.2 GA

2. HttpClient 5.3 GA

There have has no feedback to deprecation of NTLM and GGS based auth
schemes since 5.3-alpha1. I see no point waiting any longer.

^^^ GSS


3. HttpCore 5.3-alpha1 and HttpClient 5.4-alpha1

We have made many great improvements in the latest development
branches. It is time we released them.


What do you think?


Makes sense.


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

[jira] [Commented] (HTTPCLIENT-2303) a shaded version of apache http client

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2303:


I frankly don't understand the problem. The user has failed to provide a SLF4J 
binding. That's it and you failed to shade (not relocate) SLF4 API. That's it.

> a shaded version of apache http client 
> ---
>
> Key: HTTPCLIENT-2303
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2303
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Mark Zitnik
>Priority: Minor
>
> Hi Apache HTTP Client team,
> I am one of the developers of 
> [clickhouse-java|https://github.com/ClickHouse/clickhouse-java/tree/v0.5.0]. 
> Recently, we decided to use Apache HTTP Client as our default HTTP driver. We 
> have a shaded version of our driver to avoid jar conflicts when running our 
> library. Any plans to add a  shaded version of Apache HTTP Client?   



--
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-2303) a shaded version of apache http client

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2303:


What? How should we shade ourselves?

> a shaded version of apache http client 
> ---
>
> Key: HTTPCLIENT-2303
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2303
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Reporter: Mark Zitnik
>Priority: Minor
>
> Hi Apache HTTP Client team,
> I am one of the developers of 
> [clickhouse-java|https://github.com/ClickHouse/clickhouse-java/tree/v0.5.0]. 
> Recently, we decided to use Apache HTTP Client as our default HTTP driver. We 
> have a shaded version of our driver to avoid jar conflicts when running our 
> library. Any plans to add a  shaded version of Apache HTTP Client?   



--
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] (HTTPCORE-760) An error occurred in the HttpClient 4.5 Tutorial document

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-760:
-

So it is a matter of formatting, no?

> An error occurred in the HttpClient 4.5 Tutorial document
> -
>
> Key: HTTPCORE-760
> URL: https://issues.apache.org/jira/browse/HTTPCORE-760
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: 4.4.16
>Reporter: Mr.Z
>Priority: Major
> Attachments: image-2023-10-07-14-25-21-904.png
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Dear Apache HttpClient team,
> I would like to report a bug in the documentation for Apache HttpClient. 
> Specifically, I have found an error in the section on  {_}*1.1.3. Working 
> with message headers*{_}.(link: 
> [https://hc.apache.org/httpcomponents-client-4.5.x/current/tutorial/html/fundamentals.html]
>  )
> {code:java}
> HttpResponse response = new BasicHttpResponse(HttpVersion.HTTP_1_1, 
>     HttpStatus.SC_OK, "OK");
> response.addHeader("Set-Cookie", 
>     "c1=a; path=/; domain=localhost");
> response.addHeader("Set-Cookie", 
>     "c2=b; path=\"/\", c3=c; domain=\"localhost\"");HeaderElementIterator it 
> = new BasicHeaderElementIterator(
>     response.headerIterator("Set-Cookie"));while (it.hasNext()) {
>     HeaderElement elem = it.nextElement(); 
>     System.out.println(elem.getName() + " = " + elem.getValue());
>     NameValuePair[] params = elem.getParameters();
>     for (int i = 0; i < params.length; i++) {
>         System.out.println(" " + params[i]);
>     }
> } {code}
> HttpClient 4.5 Tutorial  output result written in the document is:
> {code:java}
> c1 = a
> path=/
> domain=localhost
> c2 = b
> path=/
> c3 = c
> domain=localhost {code}
> This is incorrect, the correct output should be:
> {code:java}
> c1 = a
>  path=/
>  domain=localhost
> c2 = b
>  path=/
> c3 = c
>  domain=localhost {code}
> Could you please fix the format display? This may cause trouble for 
> developers.
>  
> Here are the pictures:
> !image-2023-10-07-14-25-21-904.png!
>  
> Thank you for your attention to this matter.
> Sincerely



--
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] [Updated] (HTTPCLIENT-2302) Examples ClientCustomSSL and AsyncClientCustomSSL are misleading and insecure

[Michael Osipov (Jira)]

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

Michael Osipov updated HTTPCLIENT-2302:
---
Description: 
The examples 
[ClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
 and 
[AsyncClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java]
 both have a Javadoc comment which says:
{quote}This example demonstrates how to create secure connections with a custom 
SSL context.
{quote}
However, this is misleading or even incorrect because the code below does the 
following:
{code:java}
.loadTrustMaterial((chain, authType) -> {
final X509Certificate cert = chain[0];
return "CN=httpbin.org".equalsIgnoreCase(cert.getSubjectDN().getName());
})
{code}
This accepts the certificate as long as the subject matches, without properly 
validating it at all, allowing man-in-the-middle attacks.

This can for example be seen with the various [https://badssl.com/] subdomains. 
For example changing in the example the URL to 
[https://self-signed.badssl.com/] and changing the expected subject to 
{{"CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US"}} still 
successfully creates the connection, even though the certificate is self-signed 
and could have been issued by a malicious actor performing a MITM attack.

Ideally this section with the custom {{TrustStrategy}} should be removed 
because it is not even necessary for this example to work.
Or if you want to keep this, then there should be a big "WARNING: ..." comment 
in this line. Otherwise users might erroneously think a custom 
{{TrustStrategy}} is needed for TLS to work, or they might just keep this 
example code because their code "works", without understanding the consequences 
of this.

  was:
{+}{+}The examples 
[ClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
 and 
[AsyncClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java]
 both have a Javadoc comment which says:
{quote}This example demonstrates how to create secure connections with a custom 
SSL context.
{quote}
However, this is misleading or even incorrect because the code below does the 
following:
{code:java}
.loadTrustMaterial((chain, authType) -> {
final X509Certificate cert = chain[0];
return "CN=httpbin.org".equalsIgnoreCase(cert.getSubjectDN().getName());
})
{code}
This accepts the certificate as long as the subject matches, without properly 
validating it at all, allowing man-in-the-middle attacks.

This can for example be seen with the various [https://badssl.com/] subdomains. 
For example changing in the example the URL to 
[https://self-signed.badssl.com/] and changing the expected subject to 
{{"CN=*.badssl.com, O=BadSSL, L=San Francisco, ST=California, C=US"}} still 
successfully creates the connection, even though the certificate is self-signed 
and could have been issued by a malicious actor performing a MITM attack.

Ideally this section with the custom {{TrustStrategy}} should be removed 
because it is not even necessary for this example to work.
Or if you want to keep this, then there should be a big "WARNING: ..." comment 
in this line. Otherwise users might erroneously think a custom 
{{TrustStrategy}} is needed for TLS to work, or they might just keep this 
example code because their code "works", without understanding the consequences 
of this.


> Examples ClientCustomSSL and AsyncClientCustomSSL are misleading and insecure
> -
>
> Key: HTTPCLIENT-2302
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2302
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Marcono1234
>Priority: Major
>
> The examples 
> [ClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/ClientCustomSSL.java]
>  and 
> [AsyncClientCustomSSL|https://github.com/apache/httpcomponents-client/blob/rel/v5.2.1/httpclient5/src/test/java/org/apache/hc/client5/http/examples/AsyncClientCustomSSL.java]
>  both have a Javadoc comment which says:
> {quote}This example demonstrates how to create secure connections with a 
> custom SSL context.
> {quote}
> However, this is misleading or even incorrect because the code below does the 
&

[jira] [Commented] (HTTPCORE-759) Content-Length missing on null entity request content

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-759:
-

Can be, but not mandatory. Is our understanding correct? 

> Content-Length missing on null entity request content
> -
>
> Key: HTTPCORE-759
> URL: https://issues.apache.org/jira/browse/HTTPCORE-759
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.2.2
>Reporter: Billy Jaime Beltran
>Priority: Minor
>  Labels: easyfix
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> When making a POST request with an empty body, the following difference in 
> behaviour was observed.
> In HttpComponents 4.4.x, a null body causes a Content-Length zero header to 
> be added.
> In HttpComponents 5.2.x, a null body causes no Content-Length headers being 
> added.
> While upgrading an Apache Camel application, we noticed that this breaks 
> calls to an upstream IIS server which replies with 411 (Length Required).
> That server expects either a Content-Length 0 or a Transfer-Encoding: chunked 
> header (with a chunk-size of zero) on requests that have a body semantic 
> (POST, PUT).
> As the code currently stands written, if we manually set `Content-Length: 0` 
> a ProtocolException is thrown 
> [RequestContent.java:106|https://github.com/apache/httpcomponents-core/blob/e3c770b55602eb9e5a45dfe7c6a07a1adede2c95/httpcore5/src/main/java/org/apache/hc/core5/http/protocol/RequestContent.java#L106]
> and if we call the constructor with overwrite, this header is removed anyway 
> without being replaced. 
> The previous behaviour (4.x) is documented 
> [RequestContent.java:102|https://github.com/apache/httpcomponents-core/blob/a5c117028b7c620974304636d52f06f172f1d08b/httpcore/src/main/java/org/apache/http/protocol/RequestContent.java#L102]
>  
> A suggested fix: re-add the null check and set Content-Length to zero.



--
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] (HTTPCORE-759) Content-Length missing on null entity request content

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-759:
-

Looking at https://www.rfc-editor.org/rfc/rfc9110#name-content-length:

{quote}
A user agent SHOULD send Content-Length in a request when the method defines a 
meaning for enclosed content and it is not sending Transfer-Encoding. For 
example, a user agent normally sends Content-Length in a POST request even when 
the value is 0 (indicating empty content). A user agent SHOULD NOT send a 
Content-Length header field when the request message does not contain content 
and the method semantics do not anticipate such data.
{quote}

So the behavior is correct and sending it is wasted bytes, no? I guess for max 
compat it should be sent.. [~abernal], [~reschke]. WDYT?

> Content-Length missing on null entity request content
> -
>
> Key: HTTPCORE-759
> URL: https://issues.apache.org/jira/browse/HTTPCORE-759
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>  Components: HttpCore
>Affects Versions: 5.2.2
>Reporter: Billy Jaime Beltran
>Priority: Minor
>  Labels: easyfix
>
> When making a POST request with an empty body, the following difference in 
> behaviour was observed.
> In HttpComponents 4.4.x, a null body causes a Content-Length zero header to 
> be added.
> In HttpComponents 5.2.x, a null body causes no Content-Length headers being 
> added.
> While upgrading an Apache Camel application, we noticed that this breaks 
> calls to an upstream IIS server which replies with 411 (Length Required).
> That server expects either a Content-Length 0 or a Transfer-Encoding: chunked 
> header (with a chunk-size of zero) on requests that have a body semantic 
> (POST, PUT).
> As the code currently stands written, if we manually set `Content-Length: 0` 
> a ProtocolException is thrown 
> [RequestContent.java:106|https://github.com/apache/httpcomponents-core/blob/e3c770b55602eb9e5a45dfe7c6a07a1adede2c95/httpcore5/src/main/java/org/apache/hc/core5/http/protocol/RequestContent.java#L106]
> and if we call the constructor with overwrite, this header is removed anyway 
> without being replaced. 
> The previous behaviour (4.x) is documented 
> [RequestContent.java:102|https://github.com/apache/httpcomponents-core/blob/a5c117028b7c620974304636d52f06f172f1d08b/httpcore/src/main/java/org/apache/http/protocol/RequestContent.java#L102]
>  
> A suggested fix: re-add the null check and set Content-Length to zero.



--
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] [Comment Edited] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCORE-756 at 9/25/23 8:13 AM:
--

I agree with [~reschke], this was not appropriate. He's a well-respected person 
on that topic not some random fool. I always appreciate his feedback.


was (Author: michael-o):
I agree with [~reschke], this was not appropriate. He's a well-respected person 
on that topic. I always appreciate his feedback.

> HttpCore HTTP Semantics conformance to RFC 9110
> ---
>
> Key: HTTPCORE-756
> URL: https://issues.apache.org/jira/browse/HTTPCORE-756
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Ensure HttpCore  conforms to RFC 9110.



--
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] (HTTPCORE-756) HttpCore HTTP Semantics conformance to RFC 9110

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-756:
-

I agree with [~reschke], this was not appropriate. He's a well-respected person 
on that topic. I always appreciate his feedback.

> HttpCore HTTP Semantics conformance to RFC 9110
> ---
>
> Key: HTTPCORE-756
> URL: https://issues.apache.org/jira/browse/HTTPCORE-756
> Project: HttpComponents HttpCore
>  Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> Ensure HttpCore  conforms to RFC 9110.



--
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

Re: [VOTE] Release HttpCore 5.2.3 based on RC1

[Michael Osipov]

Am 2023-09-17 um 11:22 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.2.3.
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.3-RC1/RELEASE_NOTES-5.2.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2.3-RC1
  revision 64035

Hashes:
  
d668beff670b212ecf2ffec8bd1dd59061ee4e9ecf39e34aa4aa2fcf74426c5cd2936ea6e0b358ed2ff3efae075617c5d78e149170123387357de1de6289711a
 httpcomponents-core-5.2.3-bin.tar.gz httpcomponents-core-5.2.3-bin.tar.gz
  
48112a007c9b60405de9f87260ce39c0b4b928cc1ab0330c7fc6726805e8c47aa5de085156ca3ee1f8b0b4852650af067750bb6e3ff57ab2eba23465cdc42e64
 httpcomponents-core-5.2.3-src.tar.gz httpcomponents-core-5.2.3-src.tar.gz
  
619dde502da372ef87933afb57db5139550f11f7abcdfe50135b69d8f3b09c27b0fa7b568e2640a3eee061d71483b34ed562027762829056aafd58e65fc122d6
 httpcomponents-core-5.2.3-src.zip httpcomponents-core-5.2.3-src.zip
  
6f690f3e3179f364c0439d47c5a0ba94f3508c529359de43eae115504c821dffd05a80310b24fe2a26f693d3e9f54441707b1a50a2e93313bead1a5da784cfc9
 httpcomponents-core-5.2.3-bin.zip httpcomponents-core-5.2.3-bin.zip

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


+1


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

[jira] [Commented] (HTTPCORE-757) AbstractCharDataConsumer jams up with incomplete UTF-8 data

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-757:
-

[~olegk], I think we can conclude this issue, no?

> AbstractCharDataConsumer jams up with incomplete UTF-8 data
> ---
>
> Key: HTTPCORE-757
> URL: https://issues.apache.org/jira/browse/HTTPCORE-757
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 5.2.2
>Reporter: Simon White
>Priority: Major
> Fix For: 5.2.3, 5.3-alpha1
>
>
> While streaming UTF-8-encoded data with the async HTTP client, we observed 
> the following behaviour:
>  * After several minutes of consuming from our stream, the client jammed up 
> permanently and did not recover without a restart
> Upon closer inspection, we realised that `AbstractCharDataConsumer` (which we 
> were extending to parse our data) was receiving incomplete UTF-8 characters 
> from the end of the stream (i.e. the last character in the stream was 
> multi-byte and we hadn't yet received all bytes for it), and this was causing 
> it to go into an infinite loop on the following code:
> {code:java}
> @Override
> public final void consume(final ByteBuffer src) throws IOException {
> final CharsetDecoder charsetDecoder = getCharsetDecoder();
> while (src.hasRemaining()) {
> checkResult(charsetDecoder.decode(src, charBuffer, false));
> doDecode(false);
> }
> }{code}
> This was fairly time-consuming to figure out and required us to go deep into 
> the brain of the library.
> We don't know how this could be improved exactly, but a couple of thoughts:
>  * If this class expects a completely valid text string in the buffer with no 
> trailing bytes:
>  ** Then it should throw some exception once it detects that it's failing to 
> completely process the buffer
>  ** And the caller could deal with this somehow (either by catching this 
> exception and waiting for more data, or otherwise ensuring that the input is 
> valid before calling the consumer - though it's not clear how it could do 
> that without also having knowledge of the encoding)
>  ** Alternatively, the caller could simply bubble up the exception and let us 
> know that we shouldn't be using this class when there is only partial data. 
> That would also have helped us to diagnose the issue
>  * OTOH if this class is expected to be able to handle partially complete 
> input:
>  ** Then it should store the trailing unprocessable bytes into a buffer, and 
> prepend them to the beginning of the next input (hopefully resulting in a 
> valid UTF-8 string, though it would also have to handle the case where it 
> didn't)
>  ** This was roughly how we solved the issue on our side - we extended `
> AbstractBinDataConsumer` instead and handled the encoding ourselves



--
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-2297) Documenting HttpClient 4.x status

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2297:


We should likely put it into maintenance mode and not full feature mode.

> Documenting HttpClient 4.x status
> -
>
> Key: HTTPCLIENT-2297
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2297
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: Henri Yandell
>Priority: Major
>
> Hi HttpClient folk,
> I noticed on 
> [https://github.com/apache/httpcomponents-core/pull/416#issuecomment-1688580065]
>  that 4.x is only receiving critical security and protocol fixes. I can see 
> on the final paragraph of the homepage ( 
> [https://hc.apache.org|https://hc.apache.org/] ) that 3.x is EOL, but I'm not 
> seeing any guidance on 4.x being on a deprecation path with limited updates. 
> Is a similar notice needed on the page now for 4.x?



--
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] (HTTPCORE-757) AbstractCharDataConsumer jams up with incomplete UTF-8 data

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-757:
-

W/o looking into it, I bet you need a four-byte buffer to read bytes until you 
reach a valid UTF-8 sequences instead of single bytes.

> AbstractCharDataConsumer jams up with incomplete UTF-8 data
> ---
>
> Key: HTTPCORE-757
> URL: https://issues.apache.org/jira/browse/HTTPCORE-757
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>Affects Versions: 5.2.2
>Reporter: Simon White
>Priority: Major
> Fix For: 5.2.3, 5.3-alpha1
>
>
> While streaming UTF-8-encoded data with the async HTTP client, we observed 
> the following behaviour:
>  * After several minutes of consuming from our stream, the client jammed up 
> permanently and did not recover without a restart
> Upon closer inspection, we realised that `AbstractCharDataConsumer` (which we 
> were extending to parse our data) was receiving incomplete UTF-8 characters 
> from the end of the stream (i.e. the last character in the stream was 
> multi-byte and we hadn't yet received all bytes for it), and this was causing 
> it to go into an infinite loop on the following code:
> {code:java}
> @Override
> public final void consume(final ByteBuffer src) throws IOException {
> final CharsetDecoder charsetDecoder = getCharsetDecoder();
> while (src.hasRemaining()) {
> checkResult(charsetDecoder.decode(src, charBuffer, false));
> doDecode(false);
> }
> }{code}
> This was fairly time-consuming to figure out and required us to go deep into 
> the brain of the library.
> We don't know how this could be improved exactly, but a couple of thoughts:
>  * If this class expects a completely valid text string in the buffer with no 
> trailing bytes:
>  ** Then it should throw some exception once it detects that it's failing to 
> completely process the buffer
>  ** And the caller could deal with this somehow (either by catching this 
> exception and waiting for more data, or otherwise ensuring that the input is 
> valid before calling the consumer - though it's not clear how it could do 
> that without also having knowledge of the encoding)
>  ** Alternatively, the caller could simply bubble up the exception and let us 
> know that we shouldn't be using this class when there is only partial data. 
> That would also have helped us to diagnose the issue
>  * OTOH if this class is expected to be able to handle partially complete 
> input:
>  ** Then it should store the trailing unprocessable bytes into a buffer, and 
> prepend them to the beginning of the next input (hopefully resulting in a 
> valid UTF-8 string, though it would also have to handle the case where it 
> didn't)
>  ** This was roughly how we solved the issue on our side - we extended `
> AbstractBinDataConsumer` instead and handled the encoding ourselves



--
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-2293) HttpCore HTTP Semantics conformance to RFC 9110

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2293:


Title is wrong, no?

> HttpCore HTTP Semantics conformance to RFC 9110
> ---
>
> Key: HTTPCLIENT-2293
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2293
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>Reporter: Arturo Bernal
>Priority: Major
>




--
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

Re: [VOTE] Release HttpClient 5.3-alpha1 based on RC1

[Michael Osipov]

Am 2023-08-15 um 11:38 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpClient 5.3-alpha1.
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.3-alpha1-RC1/RELEASE_NOTES-5.3.x.txt

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

Git Tag: 5.3-alpha1-RC1
  https://github.com/apache/httpcomponents-client/tree/5.3-alpha1-RC1

Packages:
  
https://dist.apache.org/repos/dist/dev/httpcomponents/httpclient-5.3-alpha1-RC1
  revision 63458

Hashes:
  
1ab5e1ad4883363a8249b34342a41c258650144c3928c7899c4260dab71fa9a4ee2ea4171fa8ddd4a9677c9974c50d297f9992ca919e625c7db017fdec767cf0
 httpcomponents-client-5.3-alpha1-bin.zip 
httpcomponents-client-5.3-alpha1-bin.zip
  
b0e0a188ae47daf25806bcd15752d6614d392ed73683ad9de61b00646fd4f294ad908897f7edc308ef23d712a7d43a72107722a9ec1b22ec739fb70e2615dc01
 httpcomponents-client-5.3-alpha1-src.tar.gz 
httpcomponents-client-5.3-alpha1-src.tar.gz
  
c15b6474fae48002b494fcc9062afa2e469f7a4f3761f41ab8adb853b10e7c0505e5de50d568391b207e8c6fa04ae645275cecdfddc18d5c36a75798a4986ac3
 httpcomponents-client-5.3-alpha1-bin.tar.gz 
httpcomponents-client-5.3-alpha1-bin.tar.gz
  
74774793e7408b8286be83ab1617f2a1dd5641389dd846aa314dffa22b7317236d20e1a503eba63384a86900a87c4e99849016965939f7702a2c8af79837edb8
 httpcomponents-client-5.3-alpha1-src.zip 
httpcomponents-client-5.3-alpha1-src.zip

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

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


+1


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

Re: HttpClient 5.3-alpha1 release notes

[Michael Osipov]

Am 2023-08-13 um 18:18 schrieb Oleg Kalnichevski:

Folks

Please review and amend the HttpClient 5.3-alpha1 release notes as you
deem appropriate.

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


Few notes:

* Bearer, not BEARER
* GSS, not GGS



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

Re: HttpCore / HttpClient development proposal

[Michael Osipov]

On 2023/08/11 17:11:46 Oleg Kalnichevski wrote:
> On Fri, 2023-08-11 at 17:08 +0200, Michael Osipov wrote:
> > Am 2023-08-10 um 20:08 schrieb Oleg Kalnichevski:
> > > Folks
> > > 
> > > I would like to propose the following course of action. Please let
> > > me
> > > know what think.
> > > 
> > > Features in scope for HttpClient 5.4
> > > --
> > > 
> > > * RFC 9110 conformance
> > > * RFC 9111 conformance
> > > * Refctoring of synchronized sections to use lock primitives
> > 
> > Why in 5.4? 5.3 is in alpha stage, those refactorings can easily go
> > into 
> > 5.3, no?
> > 
> 
> And than what? This will likely delay the 5.3 release by a year or so.
> No feature release for another year. No Bearer authentication for
> another year, no NTLM deprecation for another year. Does this make
> sense?

I see, you are right. Let's go ahead with your proposal.

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

Re: HttpCore / HttpClient development proposal

[Michael Osipov]

Am 2023-08-11 um 17:16 schrieb Gary Gregory:

For my money, 4.x is no longer maintained, perhaps only for emergency
security fixes.


so be it, I also meant those. But two branches in 5.x is more than enough.


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

Re: HttpCore / HttpClient development proposal

[Michael Osipov]

Am 2023-08-10 um 20:08 schrieb Oleg Kalnichevski:

Folks

I would like to propose the following course of action. Please let me
know what think.

Features in scope for HttpClient 5.4
--

* RFC 9110 conformance
* RFC 9111 conformance
* Refctoring of synchronized sections to use lock primitives


Why in 5.4? 5.3 is in alpha stage, those refactorings can easily go into 
5.3, no?


We should not maintain more than 1+2 (4.x and 5.x) branches at the same 
time.


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

[jira] [Commented] (HTTPCLIENT-2283) Missing option to configure charset for classic CloseableHttpClient

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2283:


A PR on docs is the best you can do in this case.

> Missing option to configure charset for classic CloseableHttpClient
> ---
>
> Key: HTTPCLIENT-2283
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2283
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 5.2.1
>Reporter: Dominik Derwiński
>Priority: Major
>
> In http client 4 I could use ConnectionConfig.custom().setCharset & 
> BasicHttpClientConnectionManager.setConnectionConfig (or 
> PoolingHttpClientConnectionManager.setDefaultConnectionConfig) & 
> HttpClients.custom().setConnectionManager.
> In http client 5 for async client I can use 
> CharCodingConfig.custom().setCharset & 
> HttpAsyncClients.custom().setCharCodingConfig.
> I don't see an option to set this for 
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient in 
> HttpClients.custom() or elsewhere.



--
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-2283) Missing option to configure charset for classic CloseableHttpClient

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2283:


Why then not use commercial software. Then you pay for the time of others. OSS 
is a give and take. Oleg and me are making software for millions for free.

> Missing option to configure charset for classic CloseableHttpClient
> ---
>
> Key: HTTPCLIENT-2283
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2283
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 5.2.1
>Reporter: Dominik Derwiński
>Priority: Major
>
> In http client 4 I could use ConnectionConfig.custom().setCharset & 
> BasicHttpClientConnectionManager.setConnectionConfig (or 
> PoolingHttpClientConnectionManager.setDefaultConnectionConfig) & 
> HttpClients.custom().setConnectionManager.
> In http client 5 for async client I can use 
> CharCodingConfig.custom().setCharset & 
> HttpAsyncClients.custom().setCharCodingConfig.
> I don't see an option to set this for 
> org.apache.hc.client5.http.impl.classic.CloseableHttpClient in 
> HttpClients.custom() or elsewhere.



--
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

Re: [VOTE] Release HttpCore 5.2.2 based on RC2

[Michael Osipov]

Am 2023-06-16 um 16:08 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.2.2.
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.2-RC2/RELEASE_NOTES-5.2.x.txt

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

Git Tag: 5.2.2-RC2
  https://github.com/apache/httpcomponents-core/tree/5.2.2-RC2

Packages:
https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2.2-RC2
  revision 62453

Hashes:
12f8c52aefa09cdb757492384c676b40f8700185298f85d5a3313dfd8e48c9d1445ecfb8
a4371ef9ade09963b997d134af5d23ec37a1e2363847d9913ab295e4
httpcomponents-core-5.2.2-src.tar.gz httpcomponents-core-5.2.2-
src.tar.gz
3e0e12cd6d828f8b4026659ac3a2400d52d0f29e3843dc55fdd29677a8194d6c84302038
fc3adb82783319c494cbc77935517f75f661cc79884d4116b02fce35
httpcomponents-core-5.2.2-bin.tar.gz httpcomponents-core-5.2.2-
bin.tar.gz
414e7e88fc50379c19e9ecec3e42ff5dbca677faf7ae4b90168feac9d7855d90c7cbfc85
79b5a79b2639d90a6bff7d95eaf8c597ebf7b8dc9d202f7003d9da32
httpcomponents-core-5.2.2-bin.zip httpcomponents-core-5.2.2-bin.zip
fe203388c072b95ecf22e86e50344d3a841455a1f7b3b7adc3bc23b0cafc42c0e68b2042
b9ea86a58f8345ae82dec6ab60868336fc308238d5c83b176fba8859
httpcomponents-core-5.2.2-src.zip httpcomponents-core-5.2.2-src.zip

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



+1


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

[Michael Osipov]

Am 2023-06-15 um 11:10 schrieb Oleg Kalnichevski:

Please vote on releasing these packages as HttpCore 5.2.2.
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.2-RC1/RELEASE_NOTES-5.2.x.txt

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

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

Packages:
  https://dist.apache.org/repos/dist/dev/httpcomponents/httpcore-5.2.2-RC1
  revision 62431

Hashes:
  
97b939ce209243a74743ecfa1bcd3d2e77148a3aea8497d07c8b6fa0d2cf7fe7aaf74d2e3029ad78522175b77badb8b9ac9505f9010382957d6483e31e22b5c0
 httpcomponents-core-5.2.2-src.tar.gz httpcomponents-core-5.2.2-src.tar.gz
  
86a0ebf6672d39c1ed8a1619d535a302f544dfe5600ad8c66f57bf42da066233f894dbcdfb09649fc780a90e72c4e0b3ec1b6f0c52f504d7cee14bee09319112
 httpcomponents-core-5.2.2-bin.tar.gz httpcomponents-core-5.2.2-bin.tar.gz
  
4454edc8b60f44f7de93f4168ebde898747611cd031e70cd3293aa5f1a3c2d4df8770f79524da381134a3bd385e0996e9ff9067acf1362c44f2dba1383f732d7
 httpcomponents-core-5.2.2-bin.zip httpcomponents-core-5.2.2-bin.zip
  
b8aaf6bc52ff0253298e9054cd0ca73917fcc8fc0985623b06cf52fe633365c64f2e1da6956cb8e684b10441da3d5a96cacbe96d539ff57ba109d83ed71397d8
 httpcomponents-core-5.2.2-src.zip httpcomponents-core-5.2.2-src.zip

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



+1


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

Re: HttpCore 5.2.2 release notes

[Michael Osipov]

Am 2023-06-14 um 13:52 schrieb Oleg Kalnichevski:

Folks

Please review and amend the HttpCore 5.2.2 release notes as you deem
appropriate

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

That would also be the right moment to make sure HttpCore master builds
and passes all tests for you locally.


LGTM.


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

[jira] [Commented] (HTTPCORE-750) H2ConnPool creates too many conns under high load at initialization time

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-750:
-

[~Gaojie_Liu], maybe you can incentivize [~olegk] with some amount to do the 
release ASAP.

> H2ConnPool creates too many conns under high load at initialization time
> 
>
> Key: HTTPCORE-750
> URL: https://issues.apache.org/jira/browse/HTTPCORE-750
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 5.2.1
> Environment: Linux / Ubuntu / openjdk version "1.8.0_292"
>Reporter: Gaojie Liu
>Priority: Major
> Fix For: 5.2.2
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We are using httpcore5 5.2.1 and we observed that at application startup 
> time, httpclient5 could create more than 1 conn per endpoint and in some 
> cases, too many connections caused OOM issue since httpclient5 creates a pair 
> of input/output buffer per conn.
> The regression is introduced by HTTPCORE-750, which made this change:
> [https://github.com/apache/httpcomponents-core/commit/14caf43eae407c544161c7f92329e8beb42a3534]
>  
> {code:java}
>  if (poolEntry.session != null) {
>                 callback.completed(poolEntry.session);
>             } else {
>                 poolEntry.requestQueue.add(callback);
>                 if (poolEntry.sessionFuture != null && 
> poolEntry.sessionFuture.isDone()) {
>                     poolEntry.sessionFuture = null;
>                 } {code}
> When poolEntry.sessionFuture.isDone() is true, the connection is already 
> ready, but the existing logic will abandon it and create a new one, and under 
> high load, this logic could create a lot of conns per endpoint, which 
> consumes a lot of memory.
>  
> The proposed fix:
> {code:java}
> if (poolEntry.session != null) {
> callback.completed(poolEntry.session);
> } else {
> poolEntry.requestQueue.add(callback);
> if (poolEntry.sessionFuture != null && 
> poolEntry.sessionFuture.isDone()) {
> // Check whether we should recreate a new conn or not
> try {
> poolEntry.session = poolEntry.sessionFuture.get();
> while (true) {
> final FutureCallback pendingCallback = 
> poolEntry.requestQueue.poll();
> if (pendingCallback != null) {
> pendingCallback.completed(poolEntry.session);
> } else {
> break;
> }
> }
> } catch (final Exception e) {
> poolEntry.sessionFuture = null;
> }
> } {code}
> I am planning to cut a PR for this.
>  



--
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] (HTTPCORE-750) H2ConnPool creates too many conns under high load at initialization time

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCORE-750:
-

[~Gaojie_Liu], you can sponsor it...

> H2ConnPool creates too many conns under high load at initialization time
> 
>
> Key: HTTPCORE-750
> URL: https://issues.apache.org/jira/browse/HTTPCORE-750
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore
>Affects Versions: 5.2.1
> Environment: Linux / Ubuntu / openjdk version "1.8.0_292"
>Reporter: Gaojie Liu
>Priority: Major
> Fix For: 5.2.2
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> We are using httpcore5 5.2.1 and we observed that at application startup 
> time, httpclient5 could create more than 1 conn per endpoint and in some 
> cases, too many connections caused OOM issue since httpclient5 creates a pair 
> of input/output buffer per conn.
> The regression is introduced by HTTPCORE-750, which made this change:
> [https://github.com/apache/httpcomponents-core/commit/14caf43eae407c544161c7f92329e8beb42a3534]
>  
> {code:java}
>  if (poolEntry.session != null) {
>                 callback.completed(poolEntry.session);
>             } else {
>                 poolEntry.requestQueue.add(callback);
>                 if (poolEntry.sessionFuture != null && 
> poolEntry.sessionFuture.isDone()) {
>                     poolEntry.sessionFuture = null;
>                 } {code}
> When poolEntry.sessionFuture.isDone() is true, the connection is already 
> ready, but the existing logic will abandon it and create a new one, and under 
> high load, this logic could create a lot of conns per endpoint, which 
> consumes a lot of memory.
>  
> The proposed fix:
> {code:java}
> if (poolEntry.session != null) {
> callback.completed(poolEntry.session);
> } else {
> poolEntry.requestQueue.add(callback);
> if (poolEntry.sessionFuture != null && 
> poolEntry.sessionFuture.isDone()) {
> // Check whether we should recreate a new conn or not
> try {
> poolEntry.session = poolEntry.sessionFuture.get();
> while (true) {
> final FutureCallback pendingCallback = 
> poolEntry.requestQueue.poll();
> if (pendingCallback != null) {
> pendingCallback.completed(poolEntry.session);
> } else {
> break;
> }
> }
> } catch (final Exception e) {
> poolEntry.sessionFuture = null;
> }
> } {code}
> I am planning to cut a PR for this.
>  



--
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] [Closed] (HTTPASYNC-169) TrustSelfSignedStrategy

[Michael Osipov (Jira)]

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

Michael Osipov closed HTTPASYNC-169.

Resolution: Invalid

For this, there is a mailing list.

> TrustSelfSignedStrategy
> ---
>
> Key: HTTPASYNC-169
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-169
> Project: HttpComponents HttpAsyncClient
>  Issue Type: Bug
>Reporter: Anurag Agarwal
>Priority: Major
>




--
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] (HTTPASYNC-169) TrustSelfSignedStrategy

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPASYNC-169:
--

DontTrustAnyoneStrategy

> TrustSelfSignedStrategy
> ---
>
> Key: HTTPASYNC-169
> URL: https://issues.apache.org/jira/browse/HTTPASYNC-169
> Project: HttpComponents HttpAsyncClient
>  Issue Type: Bug
>Reporter: Anurag Agarwal
>Priority: Major
>




--
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] [Comment Edited] (HTTPCLIENT-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2278 at 5/26/23 8:54 AM:
-

I looked into the Javadoc again: Given that there are multiple JSSE providers 
out there and {{UnsupportedOperationException}} is clearly documented our code 
*must* be able to deal with this, IMHO regardless how old the stack is. 
Contract is contract.


was (Author: michael-o):
I looked into the Javadoc again: Given that there are multiple JSSE providers 
out there and {{UnsupportedOperationException}} is clearly documented your code 
*must* be able to deal with this, IMHO regardless how old the stack is. 
Contract is contract.

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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] [Comment Edited] (HTTPCLIENT-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov edited comment on HTTPCLIENT-2278 at 5/26/23 8:43 AM:
-

I looked into the Javadoc again: Given that there are multiple JSSE providers 
out there and {{UnsupportedOperationException}} is clearly documented your code 
*must* be able to deal with this, IMHO regardless how old the stack is. 
Contract is contract.


was (Author: michael-o):
I looked into the Javadoc again: Given that there are multiple JSSE providers 
out there and {{UnsupportedOperationException}} is clearly documented your code 
*must* be able to deal with this, IMHO.

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2278:


I looked into the Javadoc again: Given that there are multiple JSSE providers 
out there and {{UnsupportedOperationException}} is clearly documented your code 
*must* be able to deal with this, IMHO.

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2278:


[~olegk], I am inclined to close this next week unless we get a reasonable 
answer.

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2278:


Why don't you just upgrade?

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2278:


Please be precise, how old?

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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-2278) SSLIOSession should catch UnsupportedOperationException from SSLEngine.getApplicationProtocol

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-2278:


Old? How old is your stack?

> SSLIOSession should catch UnsupportedOperationException from 
> SSLEngine.getApplicationProtocol
> -
>
> Key: HTTPCLIENT-2278
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-2278
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (async)
>Affects Versions: 5.2.1
>Reporter: Arun Katkere
>Priority: Major
>
> When SSLEngine implementation is old and does not override 
> getApplicationProtocol from SSLEngine, HttpClient async fails with:
> java.lang.UnsupportedOperationException
> at javax.net.ssl.SSLEngine.getApplicationProtocol(SSLEngine.java:1283)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.doHandshake(SSLIOSession.java:429)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession.access$100(SSLIOSession.java:74)
> at 
> org.apache.hc.core5.reactor.ssl.SSLIOSession$1.inputReady(SSLIOSession.java:201)
> at 
> org.apache.hc.core5.reactor.InternalDataChannel.onIOEvent(InternalDataChannel.java:142)
> at 
> org.apache.hc.core5.reactor.InternalChannel.handleIOEvent(InternalChannel.java:51)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.processEvents(SingleCoreIOReactor.java:178)
> at 
> org.apache.hc.core5.reactor.SingleCoreIOReactor.doExecute(SingleCoreIOReactor.java:127)
> at 
> org.apache.hc.core5.reactor.AbstractSingleCoreIOReactor.execute(AbstractSingleCoreIOReactor.java:86)
> at org.apache.hc.core5.reactor.IOReactorWorker.run(IOReactorWorker.java:44)
> at java.lang.Thread.run(Thread.java:750)
> Instead, SSLIOSession should catch UnsupportedOperationException from 
> getApplicationProtocol call and fall back to HTTP1_1. getApplicationProtocol 
> was added in a later version of Java 8, and not all SSL libraries support it.
> tlsDetailsFactory from DefaultClientTlsStrategy can be potentially used to 
> work around this, but it is deprecated.



--
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-1625) Completely overhaul GSS-API-based authentication backend

[Michael Osipov (Jira)]

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

Michael Osipov commented on HTTPCLIENT-1625:


Let's leave it on Stuck until 5.3 GA lands and then make people clear that this 
is very likely not going to happen w/o a reasonable incentive.

> Completely overhaul GSS-API-based authentication backend
> 
>
> Key: HTTPCLIENT-1625
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1625
> Project: HttpComponents HttpClient
>  Issue Type: Task
>  Components: Documentation, HttpClient (classic)
>Affects Versions: 4.5
>Reporter: Michael Osipov
>Priority: Major
>  Labels: stuck, volunteers-wanted
> Fix For: Stuck
>
>
> The current implementation does not reflect the way GSS-API-based 
> authentication should be done. It has several design flaws.
> This is an umbrella task for:
> 1. Deprecate all old classes
> 2. Investigate how it has to be plugged into HttpClient
> 3. Reimplement from scratch
> 4. Thoroughly test all new stuff
> 5. Rewrite documentation
> Design notes are canonically available under: 
> https://wiki.apache.org/HttpComponents/IssueTracking/HTTPCLIENT-1625



--
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

Re: HttpClient 5.3 release planning

[Michael Osipov]

Am 2023-05-07 um 14:23 schrieb Gary Gregory:

Any thoughts on basing 5.3 on Java 11?


Benefit?

I'd expect that version 6 could upgrade Java version.


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

Re: HttpClient 5.3 release planning

[Michael Osipov]

Am 2023-05-07 um 10:54 schrieb Oleg Kalnichevski:

Folks

I would like to move forward with the HttpClient 5.3 development and
release HttpClient 5.3 alpha1 soon. To speed things up I propose that
HttpCore skips one release cycle and HttpClient 5.3 be released based
on HttpCore 5.2. There is nothing in the HttpCore 5.3.x branch that
would be required for the next release cycle of HttpClient (other than
Internationalized Domain Names (IDN) support, maybe).


Nothing ground breaking which might justify a last HttpCore 5.2.x?

Anyway, the plan is acceptable to me.

M


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

Re: Parsing RFC2231 or newer spec'd data

[Michael Osipov]

Am 2023-05-01 um 22:46 schrieb Gary Gregory:

Well, that puts a nail in that coffin. Thank you for the details.


BUT, you have to look into Apache James which has a decent MIME parser 
which we are using at work. I would say that it is enough to have one 
decent lib in ASF land than multiple mediocre ones.



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

Re: Parsing RFC2231 or newer spec'd data

[Michael Osipov]

Am 2023-05-01 um 22:14 schrieb Gary D. Gregory:

Hi All,

Over at Apache Commons FileUpload, I am helping to rework the code base for our 
upcoming 2.0 release. We have a whole package [1] of gnarly HTTP-related 
parsing for RFC2231 which I was hoping to replace with a dependency HC. (I want 
HC to be the reference for all things HTTP.) I see that we can generate forms 
with fields but I did not find any parsing. Did I miss it?


There is none, since this is a client library and also a low level 
server library. Please also be aware some of the code is logically 
flawed. See: https://issues.apache.org/jira/browse/HTTPCLIENT-2159


This code needs serious review. Many spots are based on wrong 
understandings.


Consider that File Upload comons on top of HttpCore.

M

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

[jira] [Assigned] (HTTPCLIENT-1580) Deprecate NTCredentials constructor with workstation parameter

[Michael Osipov (Jira)]

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

Michael Osipov reassigned HTTPCLIENT-1580:
--

Assignee: Michael Osipov

> Deprecate NTCredentials constructor with workstation parameter
> --
>
> Key: HTTPCLIENT-1580
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1580
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>    Reporter: Michael Osipov
>    Assignee: Michael Osipov
>Priority: Major
>  Labels: stuck, volunteers-wanted
> Fix For: 5.3-alpha1
>
>
> The underlying NTLM implemntation shall determine the localname of the 
> current workstation at runtime/request time. There is no need to supply this 
> information. Other popular implementation do not provide this attribute 
> either, e.g., curl.



--
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] [Updated] (HTTPCLIENT-1580) Deprecate NTCredentials constructor with workstation parameter

[Michael Osipov (Jira)]

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

Michael Osipov updated HTTPCLIENT-1580:
---
Fix Version/s: 5.3-alpha1
   (was: Stuck)

> Deprecate NTCredentials constructor with workstation parameter
> --
>
> Key: HTTPCLIENT-1580
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1580
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>    Reporter: Michael Osipov
>Priority: Major
>  Labels: stuck, volunteers-wanted
> Fix For: 5.3-alpha1
>
>
> The underlying NTLM implemntation shall determine the localname of the 
> current workstation at runtime/request time. There is no need to supply this 
> information. Other popular implementation do not provide this attribute 
> either, e.g., curl.



--
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] [Updated] (HTTPCLIENT-1580) Deprecate NTCredentials constructor with workstation parameter

[Michael Osipov (Jira)]

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

Michael Osipov updated HTTPCLIENT-1580:
---
Labels: volunteers-wanted  (was: stuck volunteers-wanted)

> Deprecate NTCredentials constructor with workstation parameter
> --
>
> Key: HTTPCLIENT-1580
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1580
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>    Reporter: Michael Osipov
>    Assignee: Michael Osipov
>Priority: Major
>  Labels: volunteers-wanted
> Fix For: 5.3-alpha1
>
>
> The underlying NTLM implemntation shall determine the localname of the 
> current workstation at runtime/request time. There is no need to supply this 
> information. Other popular implementation do not provide this attribute 
> either, e.g., curl.



--
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] [Closed] (HTTPCLIENT-1580) Deprecate NTCredentials constructor with workstation parameter

[Michael Osipov (Jira)]

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

Michael Osipov closed HTTPCLIENT-1580.
--
Resolution: Fixed

Merged.

> Deprecate NTCredentials constructor with workstation parameter
> --
>
> Key: HTTPCLIENT-1580
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1580
> Project: HttpComponents HttpClient
>  Issue Type: Improvement
>  Components: HttpClient (classic)
>Affects Versions: 4.4 Beta1
>    Reporter: Michael Osipov
>    Assignee: Michael Osipov
>Priority: Major
>  Labels: volunteers-wanted
> Fix For: 5.3-alpha1
>
>
> The underlying NTLM implemntation shall determine the localname of the 
> current workstation at runtime/request time. There is no need to supply this 
> information. Other popular implementation do not provide this attribute 
> either, e.g., curl.



--
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