On Sat, 29 Mar 2025 17:27:20 GMT, Patrick Strawderman wrote:
> Use `HexFormat.fromHexDigits` in URLDecoder, instead of `Integer.parseInt`.
This pull request has now been integrated.
Changeset: 03fd43fc
Author:Patrick Strawderman
Committer: Jaikiran Pai
URL:
https://git.openjdk.org/
On Tue, 15 Apr 2025 09:28:05 GMT, Volkan Yazici wrote:
>> Adds `HttpResponse::connectionLabel` method that provides an identifier for
>> the connection.
>>
>> **Implementation note:** The feature is facilitated by
>> `HttpConnection::label`, which should not be confused with
>> `HttpConnectio
On Mon, 14 Apr 2025 14:20:39 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update to minimise code changes
>
> test/jdk/java/net/URI/Test.java line 29:
>
>> 27: * 7171415 6339649 69338
On Fri, 21 Mar 2025 13:45:24 GMT, Volkan Yazici wrote:
> Adds `HttpResponse::connectionLabel` method that provides an identifier for
> the connection.
>
> **Implementation note:** The feature is facilitated by
> `HttpConnection::label`, which should not be confused with
> `HttpConnection::id`
On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the issue
> noted in https://bugs.openjdk.org/browse/JDK-8354576?
>
> As noted in that issue, the current code in the `lookupAllHostAddr()`
> function of `Inet4AddressImpl
> Hi,
>
> Enhanced exception messages are designed to hide sensitive information such
> as hostnames, IP
> addresses from exception message strings, unless the enhanced mode for the
> specific category
> has been explicitly enabled. Enhanced exceptions were first introduced in
> 8204233 in JD
On Tue, 15 Apr 2025 14:35:28 GMT, Michael McMahon wrote:
>> Hi,
>>
>> Enhanced exception messages are designed to hide sensitive information such
>> as hostnames, IP
>> addresses from exception message strings, unless the enhanced mode for the
>> specific category
>> has been explicitly enab
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
On Tue, 15 Apr 2025 12:00:10 GMT, Eirik Bjørsnøs wrote:
> Please help review this PR which disables the unspecified but long-standing
> feature where an `FtpURLConnection` is opened as a fallback for non-local
> file URLs.
>
> Before this change, if a file URL has a non-local host component, s
On Tue, 15 Apr 2025 19:08:00 GMT, Bernd wrote:
> Is there a Risk that This breaks Applications which parses Potential UNC path
> as URL (or even worse want to open them?. I am not sure if this actually ever
> worked, but) I know people are reguläres confused about file:/// (when is it
> needed
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
On Tue, 15 Apr 2025 14:30:22 GMT, Sean Mullan wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update Copyright
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java
> line 5
On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the issue
> noted in https://bugs.openjdk.org/browse/JDK-8354576?
>
> As noted in that issue, the current code in the `lookupAllHostAddr()`
> function of `Inet4AddressImpl
On Tue, 15 Apr 2025 20:09:39 GMT, Eirik Bjørsnøs wrote:
> The current behavior for _existing_ UNC paths would be unaffected by this
> change.
For the sake of completeness:
If `Files::exists` failed for a UNC path before this change, then the code
would continue to the FTP fallback and the re
On Tue, 15 Apr 2025 14:35:38 GMT, Sean Mullan wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update Copyright
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java
> line 3
Please help review this PR which disables the unspecified but long-standing
feature where an `FtpURLConnection` is opened as a fallback for non-local file
URLs.
Before this change, if a file URL has a non-local host component, say
`file://remotehost/folder/data.txt`, then the implementation wo
On Tue, 15 Apr 2025 08:58:21 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the issue
> noted in https://bugs.openjdk.org/browse/JDK-8354576?
>
> As noted in that issue, the current code in the `lookupAllHostAddr()`
> function of `Inet4AddressImpl
On Mon, 14 Apr 2025 15:19:18 GMT, Artur Barashev wrote:
>> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>>
>>
>> Any endpoint receiving any certificate which it would need to
>> validate using any signature algorithm using an MD5 hash MUST abort
>> the handshake with a
On Sat, 12 Apr 2025 06:06:58 GMT, Alan Bateman wrote:
>> Rohitash has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Add benchmark
>> - Address PR comments
>
> test/jdk/java/net/URI/Test.java line 1791:
>
>> 1789:
>> 1790: // 83530
On Tue, 15 Apr 2025 14:32:47 GMT, Sean Mullan wrote:
>> Artur Barashev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Update Copyright
>
> test/jdk/sun/security/ssl/SignatureScheme/MD5NotAllowedInTLS13CertificateSignature.java
> line 2
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
On Fri, 11 Apr 2025 18:05:00 GMT, Daniel Fuchs wrote:
>> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 188:
>>
>>> 186: private static HttpTestServer createServer(Version version,
>>> SSLContext sslContext) {
>>> 187: try {
>>> 188: r
> Adds `HttpResponse::connectionLabel` method that provides an identifier for
> the connection.
>
> **Implementation note:** The feature is facilitated by
> `HttpConnection::label`, which should not be confused with
> `HttpConnection::id`. This distinction is explained in the JavaDoc of both
>
On Thu, 10 Apr 2025 13:56:55 GMT, Daniel Fuchs wrote:
>> Volkan Yazici has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add `@implNote` to state that the built-in is always non-empty
>
> test/jdk/java/net/httpclient/HttpResponseConnection
Can I please get a review of this change which proposes to address the issue
noted in https://bugs.openjdk.org/browse/JDK-8354576?
As noted in that issue, the current code in the `lookupAllHostAddr()` function
of `Inet4AddressImpl.c` and `Inet6AddressImpl.c` has a macos specific
implementation,
On Thu, 10 Apr 2025 13:58:40 GMT, Daniel Fuchs wrote:
>> test/jdk/java/net/httpclient/HttpResponseConnectionLabelTest.java line 129:
>>
>>> 127: throw new RuntimeException("failed closing server",
>>> serverException);
>>> 128: }
>>> 129: }
>>
>> The message
> Adds `HttpResponse::connectionLabel` method that provides an identifier for
> the connection.
>
> **Implementation note:** The feature is facilitated by
> `HttpConnection::label`, which should not be confused with
> `HttpConnection::id`. This distinction is explained in the JavaDoc of both
>
On Tue, 15 Apr 2025 07:31:32 GMT, Volkan Yazici wrote:
>> If no executor is provided the HTTP/2 server will create its own. The
>> HTTP/1.1 server however will run the exchange in the dispacher thread - so
>> you need to at least provide an executor for the HTTP/1.1 server if you
>> don't want
On Tue, 15 Apr 2025 09:28:05 GMT, Volkan Yazici wrote:
>> Adds `HttpResponse::connectionLabel` method that provides an identifier for
>> the connection.
>>
>> **Implementation note:** The feature is facilitated by
>> `HttpConnection::label`, which should not be confused with
>> `HttpConnectio
On Mon, 14 Apr 2025 13:51:30 GMT, Daniel Fuchs wrote:
>> Michael McMahon has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update to minimise code changes
>
> src/java.base/share/classes/java/net/Proxy.java line 102:
>
>> 100:
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
> MD5 algorithm is prohibited by TLSv1.3 RFC to be used in certificates:
>
>
> Any endpoint receiving any certificate which it would need to
> validate using any signature algorithm using an MD5 hash MUST abort
> the handshake with a "bad_certificate" alert.
>
>
>
> The bug manifests itself wh
34 matches
Mail list logo
