On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses a regression that
>> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
>> by removing the references to SecurityManager APIs.
>>
>> When a HTTP request
On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses a regression that
>> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
>> by removing the references to SecurityManager APIs.
>>
>> When a HTTP request
Simplifying JavaRuntimeURLConnection to avoid accidentally returning
non-resource data to users.
This change has the following distinct parts:
1. Refactor code to use Node instead of directly accessing low level
ImageLocation type.
2. Remove unnecessary use of "Resource" interface and related UR
On Wed, 18 Jun 2025 12:53:56 GMT, David Beaumont wrote:
> Simplifying JavaRuntimeURLConnection to avoid accidentally returning
> non-resource data to users.
>
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level
> ImageLocation
On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses a regression that
>> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
>> by removing the references to SecurityManager APIs.
>>
>> When a HTTP request
On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses a regression that
>> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
>> by removing the references to SecurityManager APIs.
>>
>> When a HTTP request
> When the deafult SunX509KeyManagerImpl is being used we are in violation of
> TLSv1.3 RFC spec because we ignore peer supported certificate signatures sent
> to us in "signature_algorithms"/"signature_algorithms_cert" extensions:
> https://datatracker.ietf.org/doc/html/rfc8446#section-4.4.2.2
>
On Tue, 17 Jun 2025 06:55:38 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which addresses a regression that
> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
> by removing the references to SecurityManager APIs.
>
> When a HTTP request is is
On Wed, 18 Jun 2025 09:16:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this backport to JDK 25 for
> https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression
> that was introduced in JDK 24. The mainline fix was integrated a few mintues
> back through https://
On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses a regression that
>> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
>> by removing the references to SecurityManager APIs.
>>
>> When a HTTP request
On Wed, 18 Jun 2025 01:51:36 GMT, Jaikiran Pai wrote:
>> Can I please get a review for this change which addresses a regression that
>> was introduced in `HttpURLConnection` in Java 24 when we cleaned up the code
>> by removing the references to SecurityManager APIs.
>>
>> When a HTTP request
On Wed, 18 Jun 2025 08:27:32 GMT, Michael McMahon wrote:
> I'm trying to understand how this regression happened. I was looking at the
> code change for https://bugs.openjdk.org/browse/JDK-8344190 at
> https://openjdk.github.io/cr/?repo=jdk&pr=22232&range=01#sdiff-4-src/java.base/share/classes/
On Wed, 18 Jun 2025 10:54:12 GMT, Michael McMahon wrote:
>> Hi,
>>
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm
>> targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and
>> Expires attributes
>> are present in a cookie, t
Can I please get a review of this backport to JDK 25 for
https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression
that was introduced in JDK 24. The mainline fix was integrated a few mintues
back through https://github.com/openjdk/jdk/pull/25844.
-
Commit messag
On Wed, 18 Jun 2025 13:37:49 GMT, Alan Bateman wrote:
>> Happy to accept rewording here. I do want to pull out that there *is* a
>> conceptual reason for treating module names like domain authorities though,
>> or just make the code treat the whole path the same.
>> Having unexplained weirdness
On Wed, 18 Jun 2025 09:16:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this backport to JDK 25 for
> https://bugs.openjdk.org/browse/JDK-8359709? This fix addresses a regression
> that was introduced in JDK 24. The mainline fix was integrated a few mintues
> back through https://
On Wed, 18 Jun 2025 13:21:45 GMT, David Beaumont wrote:
>> src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java
>> line 56:
>>
>>> 54: // about percent encoding. However, we choose to treat the module
>>> name is if
>>> 55: // it were a URL authority (sinc
> Hi,
>
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm
> targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and
> Expires attributes
> are present in a cookie, the Max-Age should take precedence.
>
> Thanks
> Michael
Michael
On Tue, 17 Jun 2025 18:43:56 GMT, Volkan Yazici wrote:
>>> @Michael-Mc-Mahon, instead of making an exception for `max-age` and
>>> `expires`, and removing them from `assignors`, can't we convert the type of
>>> `assignors` from `Map` to `List` and add `max-age` & `expires` entries at
>>> the e
> Hi,
>
> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm
> targeting it to 26.
> We currently do not obey the rule in RFC 6265 that says if both Max-Age and
> Expires attributes
> are present in a cookie, the Max-Age should take precedence.
>
> Thanks
> Michael
Michael
On Wed, 18 Jun 2025 12:53:56 GMT, David Beaumont wrote:
> Simplifying JavaRuntimeURLConnection to avoid accidentally returning
> non-resource data to users.
>
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level
> ImageLocation
On Wed, 18 Jun 2025 13:11:00 GMT, Alan Bateman wrote:
>> Simplifying JavaRuntimeURLConnection to avoid accidentally returning
>> non-resource data to users.
>>
>> This change has the following distinct parts:
>> 1. Refactor code to use Node instead of directly accessing low level
>> ImageLocat
On Fri, 6 Jun 2025 16:19:07 GMT, Artur Barashev wrote:
>> test/jdk/sun/security/ssl/X509KeyManager/PeerConstraintsCheck.java line 1:
>>
>>> 1: /*
>>
>> I am trying to figure out when the algorithm constraints are enabled, why
>> the key isn't being selected. I don't see anywhere that you are s
> Simplifying JavaRuntimeURLConnection to avoid accidentally returning
> non-resource data to users.
>
> This change has the following distinct parts:
> 1. Refactor code to use Node instead of directly accessing low level
> ImageLocation type.
> 2. Remove unnecessary use of "Resource" interface
> SunX509 key manager should support the same certificate checks that are
> supported by PKIX key manager.
>
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while
> SunX509 supports only a single ke
On Wed, 18 Jun 2025 13:54:42 GMT, David Beaumont wrote:
>>> Happy to accept rewording here. I do want to pull out that there _is_ a
>>> conceptual reason for treating module names like domain authorities though,
>>> or just make the code treat the whole path the same. Having unexplained
>>> we
Hi Daniel,
Thank you for this reply.
In our case, the underlying thread pool doesn't typically become
overloaded, but when it does, we’re forced to manually restart applications
because the HttpClient becomes permanently stalled.
Why is it that tasks need to be executed? Dropping work can be an
a
On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeliński wrote:
> Add an exception check after a JNI static method call, and re-enable checks
> for CallStatic in JNICheck.sh test.
>
> I verified that the JNICheck test is passing on all headless and headful
> platforms I had access to (Windows, Linux
When overriding the HttpClient executor with a custom ThreadPoolExecutor
that uses the default RejectedExecutionHandler.AbortPolicy, the Java HTTP
client (java.net.http.HttpClient) becomes permanently unusable if the
delegate executor rejects a task.
This creates a situation where transient thread
On Wed, 11 Jun 2025 13:18:47 GMT, Daniel Jeliński wrote:
> Add an exception check after a JNI static method call, and re-enable checks
> for CallStatic in JNICheck.sh test.
>
> I verified that the JNICheck test is passing on all headless and headful
> platforms I had access to (Windows, Linux
On Wed, 18 Jun 2025 18:43:39 GMT, Sean Mullan wrote:
>> Hi @seanjmullan! This PR fixes both JDK-8353113 and JDK-8170706. So we have
>> 2 new unit tests, one for each issue:
>>
>> 1. `AlgorithmConstraintsCheck`: tests JDK-8170706. BTW, I'm going to update
>> the `@bug` tag in this test to `8170
On Fri, 6 Jun 2025 20:01:17 GMT, Hai-May Chao wrote:
> > > > It is nice to refactor the common code for algorithm constraints
> > > > checking into a new class, `X509KeyManagerConstraints.java`, used by
> > > > both `SunX509KeyManagerImpl` and `X509KeyManagerImpl`. However, it
> > > > looks li
> SunX509 key manager should support the same certificate checks that are
> supported by PKIX key manager.
>
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while
> SunX509 supports only a single ke
> SunX509 key manager should support the same certificate checks that are
> supported by PKIX key manager.
>
> Effectively there should be only 2 differences between 2 key managers:
> - PKIX supports multiple key stores through KeyStore.Builder interface while
> SunX509 supports only a single ke
On Wed, 18 Jun 2025 10:54:12 GMT, Michael McMahon wrote:
>> Hi,
>>
>> This is a fix to j.n.HttpCookie (which has a doc/spec change). So, I'm
>> targeting it to 26.
>> We currently do not obey the rule in RFC 6265 that says if both Max-Age and
>> Expires attributes
>> are present in a cookie, t
Hi David,
As a general rule, the client doesn't expect tasks to
be rejected by the executor. Tasks need to be executed,
one way or another, for the client to work as expected.
Executing in the current thread is often not an option
as it may lead to deadlocks.
So if we get a RejectedTaskExection,
36 matches
Mail list logo
