From myankelevich at openjdk.org  Sat Nov  1 10:09:12 2025
From: myankelevich at openjdk.org (Mikhail Yankelevich)
Date: Sat, 1 Nov 2025 10:09:12 GMT
Subject: Integrated: 8368625:
 com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently
In-Reply-To: <wUvBI9V2IF4cVMIPHOD4UuUH5kb2BaZNvxg45qO1itk=.7a9e24de-6c6e-43fc-b752-f0efeb6f825e@github.com>
References: <wUvBI9V2IF4cVMIPHOD4UuUH5kb2BaZNvxg45qO1itk=.7a9e24de-6c6e-43fc-b752-f0efeb6f825e@github.com>
Message-ID: <gowShVv2s2oacIMTo1Gq6ROzQ8UFk3KRVhvdD7wD47M=.95523159-f26a-47ae-b091-fcca43237f9c@github.com>

On Tue, 7 Oct 2025 10:11:22 GMT, Mikhail Yankelevich <myankelevich at openjdk.org> wrote:

> I believe that increasing the timeout might help, as it seems to be happening due to the machine load. I'm going to make a pr increasing the timeout to 20 from 5 (similar to what it was when timeout factor was 4).

This pull request has now been integrated.

Changeset: 13b3d2fc
Author:    Mikhail Yankelevich <myankelevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13b3d2fca1af71d0aa9908e19630c2e965dd7134
Stats:     26 lines in 1 file changed: 10 ins; 11 del; 5 mod

8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/27670

From duke at openjdk.org  Sat Nov  1 10:27:02 2025
From: duke at openjdk.org (Peyang)
Date: Sat, 1 Nov 2025 10:27:02 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v6]
In-Reply-To: <aVV6LTjo5_plwqXnUqSleXBQhCy2_wJBUnckM5GM3H4=.3589fad9-7f8f-429d-8519-5447b2e7d5eb@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <c7zlO6MqbjqGrgnK8PGItTF_yyetlwZcxWzr_8eNY8s=.634c1bab-cf8c-4522-8193-4f66e08eee81@github.com>
 <W7rjnmIDYpMVIKN_cRcN5WNP072ZeEWqBDbPd9XlfJo=.6082177d-b2a6-4c0a-8fa7-f4039cb6de1c@github.com>
 <Ipgubm_0ANsn4hZjpItn72Nzg11iIubInheuhVA8Qc0=.499fa9f3-8408-4d05-9fb6-82056b4443d2@github.com>
 <aVV6LTjo5_plwqXnUqSleXBQhCy2_wJBUnckM5GM3H4=.3589fad9-7f8f-429d-8519-5447b2e7d5eb@github.com>
Message-ID: <MNM8xdtyCxl3JauOI9q3biGtQcis7fPLITedGyqvWhk=.852dedfe-248c-420a-80b8-a89d4465875c@github.com>

On Fri, 31 Oct 2025 14:45:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I recall reading this part of the RFC before. 
>> Since it says *MAY*, and given that this is a simple web server, I wasn't sure if such validations are strictly required,
>> so I didn't implement them.
>> But if you think it's necessary, I can add them now.
>
> Yes please. I'd prefer to have built-in validation.

I implemented a check that validates whether the ranges are in ascendnig order and non-overlapping, returning an error if they are not.
However, I have some concerns: this restriction might be too strict.

Instead of outright rejecting requests with overlapping or unsorted ranges, what if the server simply combines overlapping ranges and sorts them before returning?
According to [RFC 7233 ?15.3.7.2](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7.2-4):
> When multiple ranges are requested, a server **MAY** coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding range-spec appeared in the received [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header field.  

In other words, rather than strictly validating and rejecting, we could treat this as an efficiency optimization on the server side. I think this approach would be more practical. I?d like to hear your thoughts on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2483528850

From duke at openjdk.org  Sat Nov  1 14:26:27 2025
From: duke at openjdk.org (Peyang)
Date: Sat, 1 Nov 2025 14:26:27 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v8]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <iZ2jMwH-RIFapNEHL33AFkP4MbaW_B7BRxokb-OtT4E=.35199359-0d38-4b3b-9be4-d5c2a6648446@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request incrementally with one additional commit since the last revision:

  Allow unlimited splits when parsing HTTP Range header to detect trailing commas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28021/files
  - new: https://git.openjdk.org/jdk/pull/28021/files/10872b75..41ebfd45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From duke at openjdk.org  Sat Nov  1 15:43:03 2025
From: duke at openjdk.org (EunHyunsu)
Date: Sat, 1 Nov 2025 15:43:03 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v2]
In-Reply-To: <NVfgWFEwsMLFLRuiVut4WkAWHK0PW0BeHNCaTSSxbCo=.0c0b4802-cec9-4e81-8dcf-398a3500491c@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <BTLPkaNof7Zm87wnss_ebiBA9tV0WZuGPL8tAwCYMaQ=.bcac1f3e-570d-4754-a2bc-3eaab9f1b298@github.com>
 <NVfgWFEwsMLFLRuiVut4WkAWHK0PW0BeHNCaTSSxbCo=.0c0b4802-cec9-4e81-8dcf-398a3500491c@github.com>
Message-ID: <yALyGxjyardTK-iIfGYjce2vYXESJYqZmO3sS48iYeg=.0839d202-b475-498f-b4e0-65a51a676102@github.com>

On Fri, 31 Oct 2025 15:26:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> @Michael-Mc-Mahon I believe this change doesn't require a CSR since it's just fixing an example.
> 
> @ehs208 did you generate `make docs-jdk-api` and verify that the generated API documentation correctly displays the new changes?

I built the Javadoc locally using `make docs-jdk-api` and confirmed that the
HttpClient example now renders correctly.

The `HttpRequest` declaration appears properly before the `send` call,
matching the asynchronous example style in the generated docs.

<img width="2618" height="1398" alt="image" src="https://github.com/user-attachments/assets/f2b931e5-ee42-4dd6-8373-69010e85765b" />

(Attached is a screenshot from the generated docs:)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3476469813

From duke at openjdk.org  Sat Nov  1 15:53:01 2025
From: duke at openjdk.org (EunHyunsu)
Date: Sat, 1 Nov 2025 15:53:01 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v2]
In-Reply-To: <BTLPkaNof7Zm87wnss_ebiBA9tV0WZuGPL8tAwCYMaQ=.bcac1f3e-570d-4754-a2bc-3eaab9f1b298@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <BTLPkaNof7Zm87wnss_ebiBA9tV0WZuGPL8tAwCYMaQ=.bcac1f3e-570d-4754-a2bc-3eaab9f1b298@github.com>
Message-ID: <h3mgsmQ3jilplz911FtQhhQxeOOgQgb-BKphs6SIolk=.50d1bf66-8d3b-4323-bf9a-d568dc5cb971@github.com>

On Fri, 31 Oct 2025 12:58:39 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> Fixes JDK-8371009.
>> 
>> The synchronous HttpClient example references `request` without defining it.
>> This patch adds a minimal HttpRequest initialization immediately before the
>> synchronous example (mirroring the asynchronous snippet) so the example
>> compiles and runs as-is.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply review suggestion: create client before request in HttpClient example

> > @Michael-Mc-Mahon I believe this change doesn't require a CSR since it's just fixing an example.
> > @ehs208 did you generate `make docs-jdk-api` and verify that the generated API documentation correctly displays the new changes?
> 
> I built the Javadoc locally using `make docs-jdk-api` and confirmed that the HttpClient example now renders correctly.
> 
> The `HttpRequest` declaration appears properly before the `send` call, matching the asynchronous example style in the generated docs.
> 
> <img alt="image" width="2000" height="1398" src="https://private-user-images.githubusercontent.com/109217208/508574310-f2b931e5-ee42-4dd6-8373-69010e85765b.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjIwMTE5MjEsIm5iZiI6MTc2MjAxMTYyMSwicGF0aCI6Ii8xMDkyMTcyMDgvNTA4NTc0MzEwLWYyYjkzMWU1LWVlNDItNGRkNi04MzczLTY5MDEwZTg1NzY1Yi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjUxMTAxJTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI1MTEwMVQxNTQwMjFaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT05MDZjOGZmOWIzNDY5MDQzY2EzZWZmYjAzMGE5ZjQxMDIxYzk2ODdhMjk3ODlmZjdiMTc1NWMyMjYzZjA2YTcyJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCJ9.IjKox944B5wm2sDNgA3F-niVl1ZPIA1B0b5dLSuWsS4">
> (Attached is a screenshot from the generated docs:)

Upon checking again, I noticed that the asynchronous example is indented slightly more than the synchronous one.  
It appears that this difference already existed prior to my patch.  
Just wanted to confirm whether this is intentional or if we should align the indentation for consistency.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3476475892

From ehs122100 at gmail.com  Sat Nov  1 19:14:38 2025
From: ehs122100 at gmail.com (Hyunsu Eun)
Date: Sun, 2 Nov 2025 04:14:38 +0900
Subject: Suggestion: Add null message for HttpRequest.Builder POST()
Message-ID: <EEE962D1-1008-4938-B0B3-2CE4E606673A@gmail.com>

Hello,

While reviewing the implementation of java.net.http.HttpRequest.Builder,
I noticed a small inconsistency in how null arguments are handled.

Currently, when calling POST(null), a plain NullPointerException is thrown
without any descriptive message.

Example:

HttpRequest.newBuilder()
.uri(URI.create(?https://example.com?))
.POST(null)
.build();

This produces the following stack trace:

Exception in thread ?main? java.lang.NullPointerException
at java.base/java.util.Objects.requireNonNull(Objects.java:220)
at java.net.http/jdk.internal.net.http.HttpRequestBuilderImpl.POST(HttpRequestBuilderImpl.java:180)
at org.example.Main.main(Main.java:17)

Although the cause can be inferred from Main.java:17,
the exception message itself does not clearly indicate which argument was null.

In contrast, the uri(URI) method in the same class uses
requireNonNull(uri, "uri must be non-null"),
which provides a clear and descriptive message when the argument is null.

I understand that URI is a mandatory field for every request,
while the BodyPublisher might be optional.
However, since passing a null body to POST, PUT, or
method(String, BodyPublisher) is almost always unintentional,
it may be helpful to include a similar message for these methods as well.

For example,
requireNonNull(body, "BodyPublisher must be non-null");

Adding such a message would improve clarity and consistency
with other null checks already present in this class.

I have searched for existing issues related to this behavior
but was unable to find any.
If I have overlooked something or if this suggestion is inappropriate,
please feel free to let me know.
If the proposal sounds reasonable,
I would be happy to prepare a patch and contribute it.

Thank you for your time and consideration.
Best regards,
Hyunsu Eun
GitHub: https://github.com/ehs208

From jaikiran.pai at oracle.com  Sun Nov  2 05:37:32 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Sun, 2 Nov 2025 11:07:32 +0530
Subject: Suggestion: Add null message for HttpRequest.Builder POST()
In-Reply-To: <EEE962D1-1008-4938-B0B3-2CE4E606673A@gmail.com>
References: <EEE962D1-1008-4938-B0B3-2CE4E606673A@gmail.com>
Message-ID: <049b575e-53d0-4a59-81ca-3ccfb462d9f2@oracle.com>

This proposal looks reasonable to me. I've filed 
https://bugs.openjdk.org/browse/JDK-8371091 as an enhancement request 
and you can raise a PR against that.

-Jaikiran

On 02/11/25 12:44 am, Hyunsu Eun wrote:
> Hello,
>
> While reviewing the implementation of java.net.http.HttpRequest.Builder,
> I noticed a small inconsistency in how null arguments are handled.
>
> Currently, when calling POST(null), a plain NullPointerException is thrown
> without any descriptive message.
>
> Example:
>
> HttpRequest.newBuilder()
> .uri(URI.create(?https://example.com?))
> .POST(null)
> .build();
>
> This produces the following stack trace:
>
> Exception in thread ?main? java.lang.NullPointerException
> at java.base/java.util.Objects.requireNonNull(Objects.java:220)
> at java.net.http/jdk.internal.net.http.HttpRequestBuilderImpl.POST(HttpRequestBuilderImpl.java:180)
> at org.example.Main.main(Main.java:17)
>
> Although the cause can be inferred from Main.java:17,
> the exception message itself does not clearly indicate which argument was null.
>
> In contrast, the uri(URI) method in the same class uses
> requireNonNull(uri, "uri must be non-null"),
> which provides a clear and descriptive message when the argument is null.
>
> I understand that URI is a mandatory field for every request,
> while the BodyPublisher might be optional.
> However, since passing a null body to POST, PUT, or
> method(String, BodyPublisher) is almost always unintentional,
> it may be helpful to include a similar message for these methods as well.
>
> For example,
> requireNonNull(body, "BodyPublisher must be non-null");
>
> Adding such a message would improve clarity and consistency
> with other null checks already present in this class.
>
> I have searched for existing issues related to this behavior
> but was unable to find any.
> If I have overlooked something or if this suggestion is inappropriate,
> please feel free to let me know.
> If the proposal sounds reasonable,
> I would be happy to prepare a patch and contribute it.
>
> Thank you for your time and consideration.
> Best regards,
> Hyunsu Eun
> GitHub: https://github.com/ehs208

From duke at openjdk.org  Sun Nov  2 07:30:41 2025
From: duke at openjdk.org (EunHyunsu)
Date: Sun, 2 Nov 2025 07:30:41 GMT
Subject: RFR: 8371091: Enhance npe message httprequest
Message-ID: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>

This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.

Each of these methods now calls requireNonNull(body, "BodyPublisher must not be null"), making the exception message explicit.
A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.

All builds and related tests (jdk/java/net/httpclient) have passed successfully.

Currently, only POST(), PUT(), and method() include these messages.
Some other builder methods (such as header(), setHeader(), and uri()) also throw NullPointerException without a message.
I would like to discuss whether adding consistent messages to those methods would be beneficial,
and whether the current wording "BodyPublisher must not be null" feels appropriate.

-------------

Commit messages:
 - 8271091: fixed whitespace errors
 - 8271091: Add test verifying NullPointerException messages for null BodyPublisher in HttpRequest.Builder
 - 8271091: Add descriptive NullPointerException messages for null BodyPublisher in HttpRequest.Builder methods

Changes: https://git.openjdk.org/jdk/pull/28103/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371091
  Stats: 62 lines in 2 files changed: 59 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28103/head:pull/28103

PR: https://git.openjdk.org/jdk/pull/28103

From duke at openjdk.org  Sun Nov  2 14:16:37 2025
From: duke at openjdk.org (Peyang)
Date: Sun, 2 Nov 2025 14:16:37 GMT
Subject: RFR: 8371092: NullPointerException in AltServiceUsageTest.afterClass()
 test
Message-ID: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>

- Add `safeClose(DatagramChannel)` to close udpNotResponding safely.
- Null-check and exception handling unified with `safeStop()`.
- Ensures test cleanup never fails due to uninitialized or problematic channel.

-------------

Commit messages:
 - 8371092: Avoid NPE in SimpleHttpsServerTest afterClass

Changes: https://git.openjdk.org/jdk/pull/28104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371092
  Stats: 14 lines in 1 file changed: 13 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28104/head:pull/28104

PR: https://git.openjdk.org/jdk/pull/28104

From duke at openjdk.org  Sun Nov  2 17:08:03 2025
From: duke at openjdk.org (Florent Guillaume)
Date: Sun, 2 Nov 2025 17:08:03 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v8]
In-Reply-To: <iZ2jMwH-RIFapNEHL33AFkP4MbaW_B7BRxokb-OtT4E=.35199359-0d38-4b3b-9be4-d5c2a6648446@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <iZ2jMwH-RIFapNEHL33AFkP4MbaW_B7BRxokb-OtT4E=.35199359-0d38-4b3b-9be4-d5c2a6648446@github.com>
Message-ID: <ArzMQoSSTjT1oOBM26gT3P2sBE7ilOgmDdfvUt00yho=.7a68f580-6453-40be-b487-54360bb25396@github.com>

On Sat, 1 Nov 2025 14:26:27 GMT, Peyang <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
>> 
>> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
>> 
>> This change contains:
>> 
>> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
>> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
>> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
>> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
>> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
>> 6. Includes corresponding tests to verify correct behavior.
>> 
>> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
>> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html
>
> Peyang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow unlimited splits when parsing HTTP Range header to detect trailing commas

Changes requested by efge at github.com (no known OpenJDK username).

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 344:

> 342:             try {
> 343:                 if (startStr.isEmpty()) {  // "-<suffix-length>"
> 344:                     long suffixLength = Long.parseLong(endStr, 10);

`Long.parseLong(endStr)` already parses in base 10, there's no need to be explicit about it. See the JDK code:

    public static long parseLong(String s) throws NumberFormatException {
        return parseLong(s, 10);
    }

test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java line 147:

> 145: 
> 146:                 // malformed numbers or format
> 147:                 {"bytes=-0"}, {"bytes=meow"}, {"bytes=--500"}, {"bytes=500"}, {"bytes=-"}, {"bytes=+500-600"},

Please add a test for `bytes=400--500` which uses a code path not covered by existing tests.
Also worth adding `bytes=500-+600` and variations with `+` in all possible positions, and omitting left part.
Add also `bytes=--`, `bytes=-+1`, ... I'm sure one could come up with more.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28021#pullrequestreview-3408865320
PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2484900851
PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2484909654

From vyazici at openjdk.org  Mon Nov  3 10:09:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 10:09:29 GMT
Subject: RFR: 8366575: Remove SDP support
In-Reply-To: <H97VJmEKWaQtawOkZsPaxC98RvDtUkic7x2aAf3Di6w=.a0082c59-4b61-4dff-85cb-8795d31f66e1@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
 <H97VJmEKWaQtawOkZsPaxC98RvDtUkic7x2aAf3Di6w=.a0082c59-4b61-4dff-85cb-8795d31f66e1@github.com>
Message-ID: <EoNfBEfjDYiQSbFrdqmHAyoCAiW1DL-zZBMBRiIaMA0=.a2ab4a61-c43d-4506-8ed7-a3e2a9096fee@github.com>

On Wed, 29 Oct 2025 17:23:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The only other mention of sdp I could find in the sources and test is in `ct.properties`

@dfuch, `ct.properties` is used by `javac -source 8`, and hence, should not be updated. Nevertheless, good that you raised this detail. I've created [JDK-8371133](https://bugs.openjdk.org/browse/JDK-8371133) to demystify it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3479757650

From michaelm at openjdk.org  Mon Nov  3 10:14:30 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 3 Nov 2025 10:14:30 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v6]
In-Reply-To: <fdM86qDcaEXxyfqM6UT-7Pjz73qg_0T79xTaqf4vKrY=.d0784c46-5cf7-4337-bf8a-2dc478a8ab80@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <c7zlO6MqbjqGrgnK8PGItTF_yyetlwZcxWzr_8eNY8s=.634c1bab-cf8c-4522-8193-4f66e08eee81@github.com>
 <sUPqefqumSJvgaP9K2CSY1TW2uSizx1T8VIu5GhnhkY=.e04af8b5-1927-4ad9-875c-f38b4de78368@github.com>
 <j8lzEllemz1WD1FIVOjp0HnzVrTbBl44GclsSMaj5EI=.782e21d0-063b-4294-b227-1682b4cddb63@github.com>
 <9dX_Pl6xcwpO1YgLTj_L3qkGj_Dgrbo3VS3iiztbejo=.bdd88636-83dd-44cf-8edc-c4f8fcfa1ca4@github.com>
 <fdM86qDcaEXxyfqM6UT-7Pjz73qg_0T79xTaqf4vKrY=.d0784c46-5cf7-4337-bf8a-2dc478a8ab80@github.com>
Message-ID: <avgqYYwPHiF3k9GuzYgaBcp3iChNEWOWD6U7P3lYANg=.28dd810d-b1bd-494f-9c54-1f1e7ccd2811@github.com>

On Fri, 31 Oct 2025 15:15:22 GMT, Peyang <duke at openjdk.org> wrote:

>> I'll have to check the RFC but it might be allowable to return a shorter range than was requested, but the actual range to be returned would have to have been specified in the `Content-Range` header. You would have to check the length of the file first. So, EOF wouldn't occur except in very unusual circumstances. Otherwise, yes throwing IOE would close the connection signaling the error.
>
> The `ranges` list in the arguments is constructed so that each range's end option does not exceed the file size: if a requested range goes beyond the file lengh, it is clamped accordingly.
> Therefore, I don't think any foundamental change is needed here.
> 
> We could add an `assert` (and a comment) to make this assumption explict, or possibly throw an IOE in case the file was truncated or modified during sending.

I definitely don't want code that allows a `Content-Range: bytes 1000-2000` to be written and treated as normal if the file hits EOF 10 bytes short. Even if the situation cannot arise due to higher level checks, I'd like to see IOE thrown rather than breaking from the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2485957717

From duke at openjdk.org  Mon Nov  3 10:06:45 2025
From: duke at openjdk.org (Peyang)
Date: Mon, 3 Nov 2025 10:06:45 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v9]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <ukXY0Xb3k-NGuQeDkrYM6B6aZtfP-CCm6cOGWzS9C8I=.c5494983-1313-4cd6-98bb-17f616d0eacc@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request incrementally with three additional commits since the last revision:

 - Add additional test cases for invalid HTTP Range header formats
 - Refactor parsing of HTTP Range header to remove radix specification in Long.parseLong calls
 - Add assertion to ensure end range value valid in HTTP Range header processing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28021/files
  - new: https://git.openjdk.org/jdk/pull/28021/files/41ebfd45..83b1a2b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=07-08

  Stats: 17 lines in 2 files changed: 5 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From vyazici at openjdk.org  Mon Nov  3 10:56:40 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 10:56:40 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v3]
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <aYZyfy5S1iCnjEBbfrG3QKXDwcaf7PF0Hi_4X9zU5SM=.f61c823c-231f-46b4-a00a-2a9d115fc6c9@github.com>

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Simplify exception handling in `Deadline::between`
  
  Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27973/files
  - new: https://git.openjdk.org/jdk/pull/27973/files/856aea73..31b49b78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973

PR: https://git.openjdk.org/jdk/pull/27973

From dfuchs at openjdk.org  Mon Nov  3 10:59:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 10:59:04 GMT
Subject: RFR: 8371092: NullPointerException in
 AltServiceUsageTest.afterClass() test
In-Reply-To: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
References: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
Message-ID: <TjHjxHPyzawfzGmivCj_4K5TBSKr0vrZPNodcyIQzsM=.3cfcea46-9054-4cac-bfa0-c1f40a5ef3a0@github.com>

On Sun, 2 Nov 2025 14:09:28 GMT, Peyang <duke at openjdk.org> wrote:

> - Add `safeClose(DatagramChannel)` to close udpNotResponding safely.
> - Null-check and exception handling unified with `safeStop()`.
> - Ensures test cleanup never fails due to uninitialized or problematic channel.

Please make sure to run the test locally before integrating. Networking tests are not run by github actions.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28104#pullrequestreview-3410460082

From vyazici at openjdk.org  Mon Nov  3 10:59:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 10:59:45 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v4]
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <RDEc_3qF-qpeOo4K6lfD0-O9D-6TfSQlPC6hgsflIm8=.89d75fbe-c2c0-4596-ad94-0670c91748f4@github.com>

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into bigDuration
 - Simplify exception handling in `Deadline::between`
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Move `delta == 0` in `until()` to the catch block
 - Add `DeadlineOverflowTest`
 - Fix duration overflows
 - Add `DurationOverflowTest`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27973/files
  - new: https://git.openjdk.org/jdk/pull/27973/files/31b49b78..970754a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=02-03

  Stats: 56058 lines in 676 files changed: 29516 ins; 22197 del; 4345 mod
  Patch: https://git.openjdk.org/jdk/pull/27973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973

PR: https://git.openjdk.org/jdk/pull/27973

From duke at openjdk.org  Mon Nov  3 11:12:33 2025
From: duke at openjdk.org (serhiysachkov)
Date: Mon, 3 Nov 2025 11:12:33 GMT
Subject: RFR: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with
 java.nio.file.FileSystemException
Message-ID: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>

[TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

-------------

Commit messages:
 - 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

Changes: https://git.openjdk.org/jdk/pull/28108/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28108&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361106
  Stats: 10 lines in 1 file changed: 2 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28108.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28108/head:pull/28108

PR: https://git.openjdk.org/jdk/pull/28108

From vyazici at openjdk.org  Mon Nov  3 11:36:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 11:36:44 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v6]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <FwEEGz2WBH8XiaSkShAVT1FAqAqHske2tOoUjd40glM=.2cf4f7bc-2ec3-4e58-8f5a-caf47abf83e1@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge remote-tracking branch 'upstream/master' into respBodyTime
 - Improve `HttpBodySubscriberWrapper::onTermination` JavaDoc
 - Mark `SubscriptionWrapper` as `final`
 - Replace wrapper's `preTerminationCallback` argument with a method to be extended
 - Fix `HttpClient` doc typo
 - Invoke `preTerminationCallback` at `cancel()` too
 - Move `preTerminationCallback` to `complete()`
 - Improve docs as suggested by Rajan
 - Merge remote-tracking branch 'upstream/master' into respBodyTime
 - Fix code typo
 - ... and 17 more: https://git.openjdk.org/jdk/compare/667744c3...1601a185

-------------

Changes: https://git.openjdk.org/jdk/pull/27469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=05
  Stats: 852 lines in 12 files changed: 841 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Mon Nov  3 11:36:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 11:36:48 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v5]
In-Reply-To: <wg2l9xUhyT8ydQZB32HtwNfFKY-4q0HI1euo_Jy6rPw=.7d9a26d5-3b1b-4cf3-a009-93e302bb8b39@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <drkyCgfs5H-02PtA4ll-DL-kmQT615fan6Bw-PoQHyI=.766f75df-40a3-4a82-af27-7e07dc0fd69c@github.com>
 <wg2l9xUhyT8ydQZB32HtwNfFKY-4q0HI1euo_Jy6rPw=.7d9a26d5-3b1b-4cf3-a009-93e302bb8b39@github.com>
Message-ID: <n4eaipDH-_RqA2A8ICgHULUHupAV7DG29sJx_R9bS2s=.0f489a1b-cf66-4674-8967-79513a95a915@github.com>

On Thu, 30 Oct 2025 14:43:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace wrapper's `preTerminationCallback` argument with a method to be extended
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 79:
> 
>> 77:      * A callback to be invoked before termination, whether due to the
>> 78:      * completion or failure of the subscriber, or cancellation of the
>> 79:      * subscription.
> 
> I'd suggest to also say that when a subscription is cancelled, onTermination() is called before onCancel().

Improved docs in 7c989980e19.

> src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 102:
> 
>> 100:                 } finally {
>> 101:                     if (markCancelled()) {
>> 102:                         onTermination();
> 
> I was  wondering if it would be better to have the subclasses call the appropriate method from `onCancel()` rather than have both `cancel()` and `complete()` call `onTermination()`. 
> However - thinking about it again, I believe that calling onTermination() from cancel() is the right call. 
> 
> FWIW - we should also make the private class `SubscriptionWrapper` final.

Marked `SubscriptionWrapper` as `final` in 02d2b5468e9.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486158926
PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486159462

From davidalayachew at gmail.com  Sun Nov  2 22:05:12 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Sun, 2 Nov 2025 17:05:12 -0500
Subject: HttpServer should implement AutoCloseable?
In-Reply-To: <CAA9v-_Nc-JM_JtpyHnq9H8kdZoH16WCaZP=HAA_8zbddZdSC0Q@mail.gmail.com>
References: <CAA9v-_Mem7TqqhNa6SKQPZrAOjKvzuhBka6G4U5LTNditE0nJg@mail.gmail.com>
 <2f77eeca-a9f8-4cf9-9569-0f4076b79d4f@oracle.com>
 <CAA9v-_P+SYUohrkwYQ33D39_dZoc2dsEOQVOfUT+k2k1QcsUoA@mail.gmail.com>
 <CAA9v-_Nc-JM_JtpyHnq9H8kdZoH16WCaZP=HAA_8zbddZdSC0Q@mail.gmail.com>
Message-ID: <CAA9v-_MYzw1FCxbpgksC37Zp6fiT5WZOnuQWqNWk6M5U6-WosA@mail.gmail.com>

Hello,

Sending a follow up email since I haven't heard back. If this idea is not
wanted, please do lmk. It just felt like a good enough semantic fit that it
was worth doing.

On Fri, Oct 24, 2025 at 10:56?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello @net-dev at openjdk.org <net-dev at openjdk.org>,
>
> Would it be ok if we made HttpServer from the jdk.httpserver module
> implement AutoCloseable? Having this would prevent people from forgetting
> to close the server after use. Also, there appears to be prior precedent
> with HttpExchange.
>
> The close() implementation could call stop(int delay) with a reasonable
> default. This implementation should be a default one, so that existing
> child classes that also implemented AutoCloseable lose no functionality.
>
> Thank you for your time and consideration.
> David Alayachew
>
>
> On Fri, Oct 24, 2025 at 10:51?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> Thanks Alan, I'll reattempt this thread over there.
>>
>> On Fri, Oct 24, 2025 at 1:57?AM Alan Bateman <alan.bateman at oracle.com>
>> wrote:
>>
>>> On 23/10/2025 23:09, David Alayachew wrote:
>>>
>>> Hello @core-libs-dev <core-libs-dev at openjdk.org>,
>>>
>>> Would it be ok if we made HttpServer from the jdk.httpserver module
>>> implement AutoCloseable? Having this would prevent people from forgetting
>>> to close the server after use.
>>>
>>> The close() implementation could call stop(int delay) with a reasonable
>>> default. This implementation should be a default one, so that existing
>>> child classes that also implemented AutoCloseable lose no functionality.
>>>
>>> The net-dev mailing list is where networking and HTTP issues are usually
>>> discussed. HttpExchange was retrofitted to implement AutoCloseable in JDK
>>> 14 and there may have been discussed (can't remember) about HttpServer at
>>> the time.
>>>
>>> -Alan
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251102/dc7b432e/attachment.htm>

From duke at openjdk.org  Mon Nov  3 11:54:06 2025
From: duke at openjdk.org (Peyang)
Date: Mon, 3 Nov 2025 11:54:06 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v8]
In-Reply-To: <ArzMQoSSTjT1oOBM26gT3P2sBE7ilOgmDdfvUt00yho=.7a68f580-6453-40be-b487-54360bb25396@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <iZ2jMwH-RIFapNEHL33AFkP4MbaW_B7BRxokb-OtT4E=.35199359-0d38-4b3b-9be4-d5c2a6648446@github.com>
 <ArzMQoSSTjT1oOBM26gT3P2sBE7ilOgmDdfvUt00yho=.7a68f580-6453-40be-b487-54360bb25396@github.com>
Message-ID: <OTG_0OILH7p4DNCjlZCUqCDTeu03XXVqHfXL6F2M2LQ=.c89c0af9-6cf7-431f-81dd-8c2c56072f73@github.com>

On Sun, 2 Nov 2025 17:04:22 GMT, Florent Guillaume <duke at openjdk.org> wrote:

>> Peyang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allow unlimited splits when parsing HTTP Range header to detect trailing commas
>
> test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java line 147:
> 
>> 145: 
>> 146:                 // malformed numbers or format
>> 147:                 {"bytes=-0"}, {"bytes=meow"}, {"bytes=--500"}, {"bytes=500"}, {"bytes=-"}, {"bytes=+500-600"},
> 
> Please add a test for `bytes=400--500` which uses a code path not covered by existing tests.
> Also worth adding `bytes=500-+600` and variations with `+` in all possible positions, and omitting left part.
> Add also `bytes=--`, `bytes=-+1`, ... I'm sure one could come up with more.

Thanks for your review.
I've added some of the suggested invalid range patterns to the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2486212083

From dfuchs at openjdk.org  Mon Nov  3 12:08:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 12:08:26 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder
In-Reply-To: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
Message-ID: <Vn9DTzHtzsdWXf1zziTE4Hm_YV961NhLRuOEVBmNGqg=.49f16f21-c05c-404e-b25f-85cd840ca9f0@github.com>

On Sun, 2 Nov 2025 07:19:12 GMT, EunHyunsu <duke at openjdk.org> wrote:

> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
> 
> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
> 
> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
> 
> Currently, only POST(), PUT(), and method() include these messages.
> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
> I would like to discuss whether adding consistent messages to those methods would be beneficial,
> and whether the current wording "BodyPublisher must not be null" feels appropriate.

src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestBuilderImpl.java line 226:

> 224:     @Override
> 225:     public HttpRequest.Builder method(String method, BodyPublisher body) {
> 226:         requireNonNull(method);

It seems strange to improve the message for `body` but not for `method`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28103#discussion_r2486250224

From alanb at openjdk.org  Mon Nov  3 12:21:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Nov 2025 12:21:05 GMT
Subject: RFR: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with
 java.nio.file.FileSystemException
In-Reply-To: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
References: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
Message-ID: <bdBrs0oOfj7bK7FmihN2_zDRlI2415N4vVYKotQdMGc=.8a2d5865-a6be-43ba-99e5-893655835582@github.com>

On Mon, 3 Nov 2025 11:06:35 GMT, serhiysachkov <duke at openjdk.org> wrote:

> [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

test/jdk/com/sun/net/httpserver/Test9.java line 126:

> 124:                 executor.shutdown ();
> 125:             Files.delete(smallFilePath);
> 126:             Files.delete(largeFilePath);

Wouldn't it be better to have the test wait until the HttpsServer have stopped and the executor has terminated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28108#discussion_r2486286222

From vyazici at openjdk.org  Mon Nov  3 12:24:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 12:24:50 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v7]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Simplify Javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/1601a185..cd74d1dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=05-06

  Stats: 15 lines in 3 files changed: 0 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Mon Nov  3 12:24:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 12:24:53 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v5]
In-Reply-To: <ApySFRNKxeDovP4pKqQGZVDdac0f3ZFFubf9VAkxaRU=.a596137b-dae2-43dc-a32e-49d0ee08c3d6@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <drkyCgfs5H-02PtA4ll-DL-kmQT615fan6Bw-PoQHyI=.766f75df-40a3-4a82-af27-7e07dc0fd69c@github.com>
 <ApySFRNKxeDovP4pKqQGZVDdac0f3ZFFubf9VAkxaRU=.a596137b-dae2-43dc-a32e-49d0ee08c3d6@github.com>
Message-ID: <p31M4aUjHZpcAlLkghZmJSHDZV9Kh6j_n7YMJgV7Gak=.d538f4a8-5620-41e6-8dd7-4713c8fe9546@github.com>

On Thu, 30 Oct 2025 16:17:21 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace wrapper's `preTerminationCallback` argument with a method to be extended
>
> src/java.net.http/share/classes/java/net/http/HttpClient.java line 315:
> 
>> 313:          * implementation applies it to the entire connection phase, from the
>> 314:          * moment a connection is requested until it is established. The
>> 315:          * elapsed time includes any SSL/TLS handshake.
> 
> Suggestion:
> 
>          * A connection timeout applies to the entire connection phase, from the
>          * moment a connection is requested until it is established. The
>          * elapsed time includes any SSL/TLS handshake.
> 
> This is a suggested simplification. If acceptable it could be applied to the same doc pattern elsewhere.

Improved as suggested in cd74d1dca84.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486291437

From duke at openjdk.org  Mon Nov  3 12:27:15 2025
From: duke at openjdk.org (EunHyunsu)
Date: Mon, 3 Nov 2025 12:27:15 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v2]
In-Reply-To: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
Message-ID: <uRa8ZRfCk76iHQQt-T6hqtMy48c73FuMtJr-S6A7drE=.f9197dc1-40fa-4946-9a3c-2db6545372bf@github.com>

> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
> 
> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
> 
> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
> 
> Currently, only POST(), PUT(), and method() include these messages.
> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
> I would like to discuss whether adding consistent messages to those methods would be beneficial,
> and whether the current wording "BodyPublisher must not be null" feels appropriate.

EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:

  8271091: Add NPE messages for method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28103/files
  - new: https://git.openjdk.org/jdk/pull/28103/files/169294d3..24ecfc3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28103/head:pull/28103

PR: https://git.openjdk.org/jdk/pull/28103

From duke at openjdk.org  Mon Nov  3 12:27:17 2025
From: duke at openjdk.org (EunHyunsu)
Date: Mon, 3 Nov 2025 12:27:17 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v2]
In-Reply-To: <Vn9DTzHtzsdWXf1zziTE4Hm_YV961NhLRuOEVBmNGqg=.49f16f21-c05c-404e-b25f-85cd840ca9f0@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <Vn9DTzHtzsdWXf1zziTE4Hm_YV961NhLRuOEVBmNGqg=.49f16f21-c05c-404e-b25f-85cd840ca9f0@github.com>
Message-ID: <Pxk4bwqiji-JYRa7hgSjUkU4PxV6vlji4NTo00jTbfk=.5f13df09-11e2-4e53-b0d9-fda07562bc94@github.com>

On Mon, 3 Nov 2025 12:05:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271091: Add NPE messages for method
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpRequestBuilderImpl.java line 226:
> 
>> 224:     @Override
>> 225:     public HttpRequest.Builder method(String method, BodyPublisher body) {
>> 226:         requireNonNull(method);
> 
> It seems strange to improve the message for `body` but not for `method`.

I agree for consistency. 
I'll update the `requireNonNull(method)` call to include an explicit message as well, e.g., 
`requireNonNull(method, "HTTP method must be non-null")`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28103#discussion_r2486295432

From jpai at openjdk.org  Mon Nov  3 12:33:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Nov 2025 12:33:56 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v2]
In-Reply-To: <uRa8ZRfCk76iHQQt-T6hqtMy48c73FuMtJr-S6A7drE=.f9197dc1-40fa-4946-9a3c-2db6545372bf@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <uRa8ZRfCk76iHQQt-T6hqtMy48c73FuMtJr-S6A7drE=.f9197dc1-40fa-4946-9a3c-2db6545372bf@github.com>
Message-ID: <IhcudRt2dsGsz-fbG40QtgXmteeytu-vdI7czCnovbk=.c7607f3e-952c-44e4-b403-071b7ff67bf0@github.com>

On Mon, 3 Nov 2025 12:27:15 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
>> 
>> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
>> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
>> 
>> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
>> 
>> Currently, only POST(), PUT(), and method() include these messages.
>> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
>> I would like to discuss whether adding consistent messages to those methods would be beneficial,
>> and whether the current wording "BodyPublisher must not be null" feels appropriate.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271091: Add NPE messages for method

Hello @ehs208, instead of a new test class, could you see if the existing tests in `test/jdk/java/net/httpclient/HttpRequestBuilderTest.java` can be updated for additionally checking the `NullPointerException` message wherever applicable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28103#issuecomment-3480294991

From duke at openjdk.org  Mon Nov  3 12:42:40 2025
From: duke at openjdk.org (EunHyunsu)
Date: Mon, 3 Nov 2025 12:42:40 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v2]
In-Reply-To: <IhcudRt2dsGsz-fbG40QtgXmteeytu-vdI7czCnovbk=.c7607f3e-952c-44e4-b403-071b7ff67bf0@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <uRa8ZRfCk76iHQQt-T6hqtMy48c73FuMtJr-S6A7drE=.f9197dc1-40fa-4946-9a3c-2db6545372bf@github.com>
 <IhcudRt2dsGsz-fbG40QtgXmteeytu-vdI7czCnovbk=.c7607f3e-952c-44e4-b403-071b7ff67bf0@github.com>
Message-ID: <u054sSqjsouXL2DvNKn1XzjsmtepvOXOpCxAnHEn-HI=.336208d1-1217-429b-9fd8-62254780a24d@github.com>

On Mon, 3 Nov 2025 12:31:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello @ehs208, instead of a new test class, could you see if the existing tests in `test/jdk/java/net/httpclient/HttpRequestBuilderTest.java` can be updated for additionally checking the `NullPointerException` message wherever applicable?

Thanks for the suggestion! That makes sense ? instead of keeping a separate test class,
I can move these checks into `HttpRequestBuilderTest.java`.

However, since the existing `testNull()` method focuses only on verifying that NPEs are thrown
(regardless of message content), would it make sense to add a small new test method,
say `testNullMessages()`, in the same class to verify the exception messages specifically?

That way we keep the tests co-located but with a clear separation of intent.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28103#issuecomment-3480333147

From dfuchs at openjdk.org  Mon Nov  3 12:51:19 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 12:51:19 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v7]
In-Reply-To: <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>
Message-ID: <kOwrRY_1C7Chy6pKFv0EC2ksVYmaO9THB6lY6w1Nmik=.3b2a36ef-56c0-4afa-8bdc-621f302d6714@github.com>

On Mon, 3 Nov 2025 12:24:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify Javadoc

src/java.net.http/share/classes/java/net/http/HttpClient.java line 321:

> 319:          * @throws IllegalArgumentException if the duration is non-positive
> 320:          * @see HttpRequest.Builder#timeout(Duration) Configuring timeout for
> 321:          * request execution

Did you verify what javadoc generated for that?

src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 256:

> 254:     }
> 255: 
> 256:     public void cancelTimer() {

We could leave that package private.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486358857
PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486374196

From dfuchs at openjdk.org  Mon Nov  3 13:03:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 13:03:28 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v7]
In-Reply-To: <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>
Message-ID: <OkyiA59qa0-mT__C7rL2aDHo0SJ7oa1Ssh3IZ9_pghQ=.7b0499c3-cc3f-46f6-8a5f-498deff2d531@github.com>

On Mon, 3 Nov 2025 12:24:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify Javadoc

src/java.net.http/share/classes/java/net/http/HttpRequest.java line 282:

> 280:          * @throws IllegalArgumentException if the duration is non-positive
> 281:          * @see HttpClient.Builder#connectTimeout(Duration) Configuring
> 282:          * timeout for connection establishment

Same here - please verify how this looks in generated API doc

test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java line 187:

> 185:         }
> 186: 
> 187:         private static HttpServerAdapters.HttpTestServer createServer(

Can we use imports to reduce the long class names please

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486383526
PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486403677

From vyazici at openjdk.org  Mon Nov  3 14:10:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 14:10:47 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v5]
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <CbEusg9wiFJ7Dvnlyaq3bIcxTWgIVY60rNfjbfj46NA=.601e6803-33c8-4299-9d37-4c2e0d625d24@github.com>

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into bigDuration
 - Merge remote-tracking branch 'upstream/master' into bigDuration
 - Simplify exception handling in `Deadline::between`
   
   Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
 - Move `delta == 0` in `until()` to the catch block
 - Add `DeadlineOverflowTest`
 - Fix duration overflows
 - Add `DurationOverflowTest`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27973/files
  - new: https://git.openjdk.org/jdk/pull/27973/files/970754a7..351de8c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=03-04

  Stats: 300 lines in 9 files changed: 282 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973

PR: https://git.openjdk.org/jdk/pull/27973

From duke at openjdk.org  Mon Nov  3 14:23:48 2025
From: duke at openjdk.org (serhiysachkov)
Date: Mon, 3 Nov 2025 14:23:48 GMT
Subject: RFR: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with
 java.nio.file.FileSystemException
In-Reply-To: <bdBrs0oOfj7bK7FmihN2_zDRlI2415N4vVYKotQdMGc=.8a2d5865-a6be-43ba-99e5-893655835582@github.com>
References: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
 <bdBrs0oOfj7bK7FmihN2_zDRlI2415N4vVYKotQdMGc=.8a2d5865-a6be-43ba-99e5-893655835582@github.com>
Message-ID: <N45yWIxze-A6ggOAu_RDqdI3ajSEmBztj84WXgbd2_M=.626109c0-543e-4225-891e-eada2fcc9fcb@github.com>

On Mon, 3 Nov 2025 12:18:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException
>
> test/jdk/com/sun/net/httpserver/Test9.java line 126:
> 
>> 124:                 executor.shutdown ();
>> 125:             Files.delete(smallFilePath);
>> 126:             Files.delete(largeFilePath);
> 
> Wouldn't it be better to have the test wait until the HttpsServer have stopped and the executor has terminated?

The test used 2 approaches here: deleteOnExit() and explicit delete, so my idea here to align behaviour to use single approach that will delete files, plus the stop method timeout was updated from 2 to 0 couple commits ago, so wasn't sure if it's good idea to pop it up again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28108#discussion_r2486653511

From dfuchs at openjdk.org  Mon Nov  3 14:34:02 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 14:34:02 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v5]
In-Reply-To: <CbEusg9wiFJ7Dvnlyaq3bIcxTWgIVY60rNfjbfj46NA=.601e6803-33c8-4299-9d37-4c2e0d625d24@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <CbEusg9wiFJ7Dvnlyaq3bIcxTWgIVY60rNfjbfj46NA=.601e6803-33c8-4299-9d37-4c2e0d625d24@github.com>
Message-ID: <MlG8H8xEJIm7jFMmwIFdx0jaZPEY0NLPe76BqlBJ8z4=.5bf85774-3fe4-4d0d-b5ab-ebc9e04ef9c5@github.com>

On Mon, 3 Nov 2025 14:10:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into bigDuration
>  - Merge remote-tracking branch 'upstream/master' into bigDuration
>  - Simplify exception handling in `Deadline::between`
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Move `delta == 0` in `until()` to the catch block
>  - Add `DeadlineOverflowTest`
>  - Fix duration overflows
>  - Add `DurationOverflowTest`

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 43:

> 41:  * numeric overflow, {@link #plus(Duration) plus()} will return
> 42:  * {@link Deadline#MAX} if the provided duration is positive,
> 43:  * {@link Deadline#MIN} otherwise.

Instead of speaking of overflow I wonder if we should say:


Operations that add durations to a {@code Deadline}, whether represented as
a `Duration` or as a `long` time increment (such as seconds or nano seconds) do
not throw if the resulting {@code Deadline} would exceed {@link #MAX} or be less
than {@link #MIN}. Instead, {@code MAX} or {@code MIN} are returned, respectively.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486686631

From vyazici at openjdk.org  Mon Nov  3 14:36:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 14:36:26 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v8]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Shorten `TimeoutResponseTestSupport` using imports
 - Make `MultiExchange::cancelTimer` package-private
 - Merge remote-tracking branch 'upstream/master' into respBodyTime
 - Simplify Javadoc
 - Merge remote-tracking branch 'upstream/master' into respBodyTime
 - Improve `HttpBodySubscriberWrapper::onTermination` JavaDoc
 - Mark `SubscriptionWrapper` as `final`
 - Replace wrapper's `preTerminationCallback` argument with a method to be extended
 - Fix `HttpClient` doc typo
 - Invoke `preTerminationCallback` at `cancel()` too
 - ... and 21 more: https://git.openjdk.org/jdk/compare/ef464d69...55396846

-------------

Changes: https://git.openjdk.org/jdk/pull/27469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=07
  Stats: 840 lines in 12 files changed: 829 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Mon Nov  3 14:36:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 14:36:30 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v7]
In-Reply-To: <kOwrRY_1C7Chy6pKFv0EC2ksVYmaO9THB6lY6w1Nmik=.3b2a36ef-56c0-4afa-8bdc-621f302d6714@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>
 <kOwrRY_1C7Chy6pKFv0EC2ksVYmaO9THB6lY6w1Nmik=.3b2a36ef-56c0-4afa-8bdc-621f302d6714@github.com>
Message-ID: <XDOCu5VxkLfsH6ML3VYvs5beLBHp0pzabMWT-V-rwQo=.d71442fd-04aa-4b14-87a2-be4f61605e07@github.com>

On Mon, 3 Nov 2025 12:46:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify Javadoc
>
> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 256:
> 
>> 254:     }
>> 255: 
>> 256:     public void cancelTimer() {
> 
> We could leave that package private.

Implemented in 6d467a8f3cf.

> test/jdk/java/net/httpclient/TimeoutResponseTestSupport.java line 187:
> 
>> 185:         }
>> 186: 
>> 187:         private static HttpServerAdapters.HttpTestServer createServer(
> 
> Can we use imports to reduce the long class names please

Implemented in 55396846d1a.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486695255
PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486694312

From vyazici at openjdk.org  Mon Nov  3 14:42:25 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 14:42:25 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v7]
In-Reply-To: <kOwrRY_1C7Chy6pKFv0EC2ksVYmaO9THB6lY6w1Nmik=.3b2a36ef-56c0-4afa-8bdc-621f302d6714@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <pu4bzWe8pUUOGEFTSnM8I5E6Hl75NoQseNKMpqaCbDo=.186a7e50-3eeb-4e24-ac28-c2eacf2e861a@github.com>
 <kOwrRY_1C7Chy6pKFv0EC2ksVYmaO9THB6lY6w1Nmik=.3b2a36ef-56c0-4afa-8bdc-621f302d6714@github.com>
Message-ID: <qEASJOZn4dDKZDn0Slxo4hdJMmZnRy97Ar0pVSknAGw=.40199650-40d5-4ff8-9c41-9d17a706c4d1@github.com>

On Mon, 3 Nov 2025 12:40:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify Javadoc
>
> src/java.net.http/share/classes/java/net/http/HttpClient.java line 321:
> 
>> 319:          * @throws IllegalArgumentException if the duration is non-positive
>> 320:          * @see HttpRequest.Builder#timeout(Duration) Configuring timeout for
>> 321:          * request execution
> 
> Did you verify what javadoc generated for that?

<img width="894" height="524" alt="image" src="https://github.com/user-attachments/assets/c2b3666c-f0cd-4060-9088-0d812bf6cdab" />

> src/java.net.http/share/classes/java/net/http/HttpRequest.java line 282:
> 
>> 280:          * @throws IllegalArgumentException if the duration is non-positive
>> 281:          * @see HttpClient.Builder#connectTimeout(Duration) Configuring
>> 282:          * timeout for connection establishment
> 
> Same here - please verify how this looks in generated API doc

<img width="894" height="602" alt="image" src="https://github.com/user-attachments/assets/19d6f6b2-5704-431e-818d-14e739717855" />

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486707602
PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486712247

From vyazici at openjdk.org  Mon Nov  3 14:42:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 14:42:29 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v8]
In-Reply-To: <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>
Message-ID: <rqA1bkaG2EA1OS4Qo8Sghx5c3sivBDVi02pNh9wPfWA=.e6db29cc-62de-401a-9232-ba2cb3a74b06@github.com>

On Mon, 3 Nov 2025 14:36:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Shorten `TimeoutResponseTestSupport` using imports
>  - Make `MultiExchange::cancelTimer` package-private
>  - Merge remote-tracking branch 'upstream/master' into respBodyTime
>  - Simplify Javadoc
>  - Merge remote-tracking branch 'upstream/master' into respBodyTime
>  - Improve `HttpBodySubscriberWrapper::onTermination` JavaDoc
>  - Mark `SubscriptionWrapper` as `final`
>  - Replace wrapper's `preTerminationCallback` argument with a method to be extended
>  - Fix `HttpClient` doc typo
>  - Invoke `preTerminationCallback` at `cancel()` too
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/ef464d69...55396846

src/java.net.http/share/classes/java/net/http/WebSocket.java line 151:

> 149:          * moment a connection is requested until it is established. The elapsed
> 150:          * time includes any SSL/TLS handshake.
> 151:          *

Generated output LGTM:
<img width="879" height="373" alt="image" src="https://github.com/user-attachments/assets/51159fad-0134-4b5d-bb78-22bb91db5108" />

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2486716503

From dfuchs at openjdk.org  Mon Nov  3 14:53:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 14:53:46 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v5]
In-Reply-To: <CbEusg9wiFJ7Dvnlyaq3bIcxTWgIVY60rNfjbfj46NA=.601e6803-33c8-4299-9d37-4c2e0d625d24@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <CbEusg9wiFJ7Dvnlyaq3bIcxTWgIVY60rNfjbfj46NA=.601e6803-33c8-4299-9d37-4c2e0d625d24@github.com>
Message-ID: <3j-J4T7hnbLu0Fl7xS4ooEvSKDbCTAJPgUxPUedWSxs=.524c9ba0-2880-48d4-9a87-7487887445cb@github.com>

On Mon, 3 Nov 2025 14:10:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into bigDuration
>  - Merge remote-tracking branch 'upstream/master' into bigDuration
>  - Simplify exception handling in `Deadline::between`
>    
>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>  - Move `delta == 0` in `until()` to the catch block
>  - Add `DeadlineOverflowTest`
>  - Fix duration overflows
>  - Add `DurationOverflowTest`

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 43:

> 41:  * numeric overflow, {@link #plus(Duration) plus()} will return
> 42:  * {@link Deadline#MAX} if the provided duration is positive,
> 43:  * {@link Deadline#MIN} otherwise.

Suggestion:

 * <p id="overflow"> Operations that add durations to a {@code Deadline}, whether 
 * represented as a `Duration` or as a `long` time increment (such as seconds or nano
 * seconds) do not throw on numeric overflow if the resulting {@code Deadline} would 
 * exceed {@link #MAX} or be less than {@link #MIN}. Instead, {@code MAX} or {@code MIN}
 * are returned, respectively.

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 61:

> 59:      * This instance is immutable and unaffected by this method call.
> 60:      * <p>
> 61:      * On numeric overflows, this method will return {@link Deadline#MAX} if

Suggestion:

     * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 107:

> 105:      * This instance is immutable and unaffected by this method call.
> 106:      * <p>
> 107:      * On numeric overflows, this method will return {@link Deadline#MIN} if

Suggestion:

     * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MIN} if

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 131:

> 129:      * This instance is immutable and unaffected by this method call.
> 130:      * <p>
> 131:      * On numeric overflows, this method will return {@link Deadline#MAX} if

Suggestion:

     * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 155:

> 153:      * This instance is immutable and unaffected by this method call.
> 154:      * <p>
> 155:      * On numeric overflows, this method will return {@link Deadline#MAX} if

Suggestion:

     * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 175:

> 173:      * This instance is immutable and unaffected by this method call.
> 174:      * <p>
> 175:      * On numeric overflows, this method will return {@link Deadline#MAX} if

Suggestion:

     * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 195:

> 193:      * This instance is immutable and unaffected by this method call.
> 194:      * <p>
> 195:      * On numeric overflows, this method will return {@link Deadline#MAX} if

Suggestion:

     * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486703151
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486706972
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486717294
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486719109
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486722302
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486724207
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2486726049

From dfuchs at openjdk.org  Mon Nov  3 15:39:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 15:39:13 GMT
Subject: RFR: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with
 java.nio.file.FileSystemException
In-Reply-To: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
References: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
Message-ID: <UAyJ4kGH8RYPtfMyIl_4trFRx00mTtWLW33SqaCfVrk=.7b2b318e-e568-4913-88bf-59b943b4db84@github.com>

On Mon, 3 Nov 2025 11:06:35 GMT, serhiysachkov <duke at openjdk.org> wrote:

> [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28108#pullrequestreview-3411616876

From dfuchs at openjdk.org  Mon Nov  3 15:39:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 15:39:16 GMT
Subject: RFR: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with
 java.nio.file.FileSystemException
In-Reply-To: <N45yWIxze-A6ggOAu_RDqdI3ajSEmBztj84WXgbd2_M=.626109c0-543e-4225-891e-eada2fcc9fcb@github.com>
References: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
 <bdBrs0oOfj7bK7FmihN2_zDRlI2415N4vVYKotQdMGc=.8a2d5865-a6be-43ba-99e5-893655835582@github.com>
 <N45yWIxze-A6ggOAu_RDqdI3ajSEmBztj84WXgbd2_M=.626109c0-543e-4225-891e-eada2fcc9fcb@github.com>
Message-ID: <q_GK_8dKteXVcjXp4AkvImrz6BUVzrZHjYkmOpY5bBU=.cfdd0138-39cf-4d8a-960e-fda7c2799251@github.com>

On Mon, 3 Nov 2025 14:20:29 GMT, serhiysachkov <duke at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/Test9.java line 126:
>> 
>>> 124:                 executor.shutdown ();
>>> 125:             Files.delete(smallFilePath);
>>> 126:             Files.delete(largeFilePath);
>> 
>> Wouldn't it be better to have the test wait until the HttpsServer have stopped and the executor has terminated?
>
> The test used 2 approaches here: deleteOnExit() and explicit delete, so my idea here to align behaviour to use single approach that will delete files, plus the stop method timeout was updated from 2 to 0 couple commits ago, so wasn't sure if it's good idea to pop it up again.

We could simply let `jtreg` do the deletion. We run these tests in `/othervm` so `deleteOnExit()` is a possibility.
Alternative would be to call `stop(Integer.MAX_VALUE)` and `executor.close()` - but then we'd need to be sure the the fixes to `HttpServer::stop` have been backported wherever this fix will be backported.
If `deleteOnExit()` solves the issue I'm OK with it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28108#discussion_r2486924508

From dfuchs at openjdk.org  Mon Nov  3 16:01:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 16:01:44 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v6]
In-Reply-To: <MNM8xdtyCxl3JauOI9q3biGtQcis7fPLITedGyqvWhk=.852dedfe-248c-420a-80b8-a89d4465875c@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <c7zlO6MqbjqGrgnK8PGItTF_yyetlwZcxWzr_8eNY8s=.634c1bab-cf8c-4522-8193-4f66e08eee81@github.com>
 <W7rjnmIDYpMVIKN_cRcN5WNP072ZeEWqBDbPd9XlfJo=.6082177d-b2a6-4c0a-8fa7-f4039cb6de1c@github.com>
 <Ipgubm_0ANsn4hZjpItn72Nzg11iIubInheuhVA8Qc0=.499fa9f3-8408-4d05-9fb6-82056b4443d2@github.com>
 <aVV6LTjo5_plwqXnUqSleXBQhCy2_wJBUnckM5GM3H4=.3589fad9-7f8f-429d-8519-5447b2e7d5eb@github.com>
 <MNM8xdtyCxl3JauOI9q3biGtQcis7fPLITedGyqvWhk=.852dedfe-248c-420a-80b8-a89d4465875c@github.com>
Message-ID: <0v49K19iLf33_xI6mfN5l3BziRkCPUqeIoiyCp8lRa0=.2230a7d3-7ebc-44e6-9e08-d2d5422bdfc7@github.com>

On Sat, 1 Nov 2025 10:24:45 GMT, Peyang <duke at openjdk.org> wrote:

>> Yes please. I'd prefer to have built-in validation.
>
> I implemented a check that validates whether the ranges are in ascendnig order and non-overlapping, returning an error if they are not.
> However, I have some concerns: this restriction might be too strict.
> 
> Instead of outright rejecting requests with overlapping or unsorted ranges, what if the server simply combines overlapping ranges and sorts them before returning?
> According to [RFC 7233 ?15.3.7.2](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7.2-4):
>> When multiple ranges are requested, a server **MAY** coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding range-spec appeared in the received [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header field.  
> 
> In other words, rather than strictly validating and rejecting, we could treat this as an efficiency optimization on the server side. I think this approach would be more practical. I?d like to hear your thoughts on this.

That would be fine too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2487001106

From daniel.fuchs at oracle.com  Mon Nov  3 16:03:36 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 3 Nov 2025 16:03:36 +0000
Subject: HttpServer should implement AutoCloseable?
In-Reply-To: <CAA9v-_MYzw1FCxbpgksC37Zp6fiT5WZOnuQWqNWk6M5U6-WosA@mail.gmail.com>
References: <CAA9v-_Mem7TqqhNa6SKQPZrAOjKvzuhBka6G4U5LTNditE0nJg@mail.gmail.com>
 <2f77eeca-a9f8-4cf9-9569-0f4076b79d4f@oracle.com>
 <CAA9v-_P+SYUohrkwYQ33D39_dZoc2dsEOQVOfUT+k2k1QcsUoA@mail.gmail.com>
 <CAA9v-_Nc-JM_JtpyHnq9H8kdZoH16WCaZP=HAA_8zbddZdSC0Q@mail.gmail.com>
 <CAA9v-_MYzw1FCxbpgksC37Zp6fiT5WZOnuQWqNWk6M5U6-WosA@mail.gmail.com>
Message-ID: <4a545e96-839c-4137-855b-f9af0fe59da0@oracle.com>

Hi David,

That sounds like something worthwhile.

best regards,

-- daniel

On 02/11/2025 22:05, David Alayachew wrote:
> Hello,
> 
> Sending a follow up email since I haven't heard back. If this idea is 
> not wanted, please do lmk. It just felt like a good enough semantic fit 
> that it was worth doing.
> 


From dfuchs at openjdk.org  Mon Nov  3 16:11:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 16:11:28 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v2]
In-Reply-To: <h3mgsmQ3jilplz911FtQhhQxeOOgQgb-BKphs6SIolk=.50d1bf66-8d3b-4323-bf9a-d568dc5cb971@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <BTLPkaNof7Zm87wnss_ebiBA9tV0WZuGPL8tAwCYMaQ=.bcac1f3e-570d-4754-a2bc-3eaab9f1b298@github.com>
 <h3mgsmQ3jilplz911FtQhhQxeOOgQgb-BKphs6SIolk=.50d1bf66-8d3b-4323-bf9a-d568dc5cb971@github.com>
Message-ID: <DqyOYaJtgK-Zi-PX1QHnuvbTYrJ3WxojeXzTCLDQBVY=.258e0580-379a-4a69-b15c-1950727a867c@github.com>

On Sat, 1 Nov 2025 15:50:33 GMT, EunHyunsu <duke at openjdk.org> wrote:

>Upon checking again, I noticed that the asynchronous example is indented slightly more than the synchronous one.
> It appears that this difference already existed prior to my patch.
> Just wanted to confirm whether this is intentional or if we should align the indentation for consistency.

It looks like it's only the first line in the asynchronous example that is misaligned. It would be good to fix it along in this PR. Thanks for catching this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3481310861

From jpai at openjdk.org  Mon Nov  3 16:15:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 3 Nov 2025 16:15:50 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v2]
In-Reply-To: <u054sSqjsouXL2DvNKn1XzjsmtepvOXOpCxAnHEn-HI=.336208d1-1217-429b-9fd8-62254780a24d@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <uRa8ZRfCk76iHQQt-T6hqtMy48c73FuMtJr-S6A7drE=.f9197dc1-40fa-4946-9a3c-2db6545372bf@github.com>
 <IhcudRt2dsGsz-fbG40QtgXmteeytu-vdI7czCnovbk=.c7607f3e-952c-44e4-b403-071b7ff67bf0@github.com>
 <u054sSqjsouXL2DvNKn1XzjsmtepvOXOpCxAnHEn-HI=.336208d1-1217-429b-9fd8-62254780a24d@github.com>
Message-ID: <5B3wKzsQnst9zPxsqwsVI21oYyZ3hU4wQhZ_QtteFSc=.9e0edcdb-db86-423a-ad8a-45f7be03c178@github.com>

On Mon, 3 Nov 2025 12:40:27 GMT, EunHyunsu <duke at openjdk.org> wrote:

> would it make sense to add a small new test method,
say testNullMessages(), in the same class to verify the exception messages specifically?

I think that should be OK. It doesn't have to be too complicated/generic either, as long as it tests these specific method calls.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28103#issuecomment-3481344136

From dfuchs at openjdk.org  Mon Nov  3 16:19:45 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Nov 2025 16:19:45 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a VirtualThread
Message-ID: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>

This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.

The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.

-------------

Commit messages:
 - Add a new test
 - Merge branch 'master' into quic-vt-8369920
 - Merge branch 'master' into quic-vt-8369920
 - Draft - 8369920: HttpClient QuicSelectorThread could be a VirtualThread

Changes: https://git.openjdk.org/jdk/pull/27827/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369920
  Stats: 288 lines in 3 files changed: 277 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/27827.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27827/head:pull/27827

PR: https://git.openjdk.org/jdk/pull/27827

From duke at openjdk.org  Mon Nov  3 17:29:46 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Nov 2025 17:29:46 GMT
Subject: RFR: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails with
 java.nio.file.FileSystemException
In-Reply-To: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
References: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
Message-ID: <IDBP0BnDVUFEsM7pa_F6nJdwm6aLq08_tOON5JArLiE=.866b9197-4cc1-4b73-ba9a-1397a0fda4b9@github.com>

On Mon, 3 Nov 2025 11:06:35 GMT, serhiysachkov <duke at openjdk.org> wrote:

> [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

@serhiysachkov 
Your change (at version f05fe8e4f3cf2caa3a9d23cd6d0f952de2ae52b4) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28108#issuecomment-3481695404

From davidalayachew at gmail.com  Mon Nov  3 17:31:22 2025
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 3 Nov 2025 12:31:22 -0500
Subject: HttpServer should implement AutoCloseable?
In-Reply-To: <4a545e96-839c-4137-855b-f9af0fe59da0@oracle.com>
References: <CAA9v-_Mem7TqqhNa6SKQPZrAOjKvzuhBka6G4U5LTNditE0nJg@mail.gmail.com>
 <2f77eeca-a9f8-4cf9-9569-0f4076b79d4f@oracle.com>
 <CAA9v-_P+SYUohrkwYQ33D39_dZoc2dsEOQVOfUT+k2k1QcsUoA@mail.gmail.com>
 <CAA9v-_Nc-JM_JtpyHnq9H8kdZoH16WCaZP=HAA_8zbddZdSC0Q@mail.gmail.com>
 <CAA9v-_MYzw1FCxbpgksC37Zp6fiT5WZOnuQWqNWk6M5U6-WosA@mail.gmail.com>
 <4a545e96-839c-4137-855b-f9af0fe59da0@oracle.com>
Message-ID: <CAA9v-_OwQz2RUofsZzqkCQpT1pex33Tpe9QBeoxJHiobpjF+FA@mail.gmail.com>

?

David reacted via Gmail
<https://www.google.com/gmail/about/?utm_source=gmail-in-product&utm_medium=et&utm_campaign=emojireactionemail#app>

On Mon, Nov 3, 2025, 11:03?AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi David,
>
> That sounds like something worthwhile.
>
> best regards,
>
> -- daniel
>
> On 02/11/2025 22:05, David Alayachew wrote:
> > Hello,
> >
> > Sending a follow up email since I haven't heard back. If this idea is
> > not wanted, please do lmk. It just felt like a good enough semantic fit
> > that it was worth doing.
> >
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/vnd.google.email-reaction+json
Size: 37 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251103/013576fc/attachment.bin>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251103/013576fc/attachment.htm>

From duke at openjdk.org  Mon Nov  3 20:18:32 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 3 Nov 2025 20:18:32 GMT
Subject: RFR: 8349670: HttpServer: sending interim responses fails after
 JDK-7026262 [v21]
In-Reply-To: <T8AV10lAyOGIxar_42u8dGv-EtkN-VL1wAMEnBAxMSI=.6ee84aca-0033-4763-a647-389c643a17a3@github.com>
References: <E4kSb-7X1RX3KPFhrMjP4rEWcxppGmLIfn8RAlpMjv8=.9b5604f9-3488-4384-bbcc-15b7e4dfbc21@github.com>
 <T8AV10lAyOGIxar_42u8dGv-EtkN-VL1wAMEnBAxMSI=.6ee84aca-0033-4763-a647-389c643a17a3@github.com>
Message-ID: <chQIZmH3yKdPmedKM0USjh_6RLgj-UXbRCKH82tHzoM=.a329be9e-1485-44d6-b774-c1fc81ea2f26@github.com>

On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. 
>> 
>> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely.
>> - sentHeaders will not be set to true when sending 1xx status codes
>> - 100-continue will be sent automatically when trying to read the inputstream if `Expect: 100-continue` header is present
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Send1xxResponsesTest.java

closing as there are better ways to handle 100-continue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3482410665

From duke at openjdk.org  Mon Nov  3 20:18:34 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 3 Nov 2025 20:18:34 GMT
Subject: Withdrawn: 8349670: HttpServer: sending interim responses fails after
 JDK-7026262
In-Reply-To: <E4kSb-7X1RX3KPFhrMjP4rEWcxppGmLIfn8RAlpMjv8=.9b5604f9-3488-4384-bbcc-15b7e4dfbc21@github.com>
References: <E4kSb-7X1RX3KPFhrMjP4rEWcxppGmLIfn8RAlpMjv8=.9b5604f9-3488-4384-bbcc-15b7e4dfbc21@github.com>
Message-ID: <B2CU4x_CqfCwjxPO-pK35ZwZhHWM0UgWI_3gh9JVBu4=.801161fb-0c88-4d03-8c69-3ac7263ff421@github.com>

On Wed, 3 Sep 2025 12:06:45 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. 
> 
> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely.
> - sentHeaders will not be set to true when sending 1xx status codes
> - 100-continue will be sent automatically when trying to read the inputstream if `Expect: 100-continue` header is present

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27069

From vyazici at openjdk.org  Mon Nov  3 21:19:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 3 Nov 2025 21:19:55 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread
In-Reply-To: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
Message-ID: <IiOIdIInKhx-4Sr94StYcVgtvGLFTOtBk5BI-i569QA=.f962f348-e168-4518-9e20-195786108e30@github.com>

On Wed, 15 Oct 2025 15:58:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
> 
> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 148:

> 146:         MAX_BUFFERED_LOW = maxBufferLow;
> 147:         String useVtForSelector =
> 148:                 System.getProperty("jdk.internal.httpclient.quic.useVTForSelector", "default");

We already have a `jdk.internal.httpclient.quic.poller.usePlatformThreads`. To follow the same naming convention, you might consider renaming this to `j.i.h.q.selector.useVirtualThreads`.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicSelector.java line 510:

> 508:     }
> 509: 
> 510:     private record QuicSelectorThread(Thread thread) {

AFAICS, all methods ? `start()`, `join()`, `ofPlatform()`, `ofVirtual()`, and `of()` ? can be `private`.

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 54:

> 52:  * @bug 8369920
> 53:  * @summary Basic test to verify that the QuicSelector
> 54:  *          uses a VirtualThread

Suggestion:

 * @summary Verifies whether `QuicSelector` uses virtual threads when
            no explicit configuration is provided

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 57:

> 55:  * @library /test/lib /test/jdk/java/net/httpclient/lib
> 56:  * @build jdk.test.lib.net.SimpleSSLContext
> 57:  *        jdk.httpclient.test.lib.common.HttpServerAdapters

@sormuras, in this JUnit test, given these `@build` classes are already included in `@library`, do we still need this explicit `@build`?

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 66:

> 64:  * @bug 8369920
> 65:  * @summary Basic test to verify that the QuicSelector
> 66:  *          uses a VirtualThread

This summary contradicts with this particular `@test`. That is, this `@test` verifies `QuicSelector` does *not* use a virtual thread. While I agree that `@test id=...` hints about the semantics, having an accurate `@summary` would not hurt:

Suggestion:

 * @summary Verifies that `QuicSelector` does *not* use virtual threads
            when explicitly configured so

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 79:

> 77:  * @bug 8369920
> 78:  * @summary Basic test to verify that the QuicSelector
> 79:  *          uses a VirtualThread

Suggestion:

 * @summary Verifies that `QuicSelector` does *always* use virtual threads
            when explicitly configured so

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 92:

> 90:  * @bug 8369920
> 91:  * @summary Basic test to verify that the QuicSelector
> 92:  *          uses a VirtualThread

Suggestion:

 * @summary Verifies whether `QuicSelector` uses virtual threads when
            `default` is explicitly configured

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 105:

> 103:  * @bug 8369920
> 104:  * @summary Basic test to verify that the QuicSelector
> 105:  *          uses a VirtualThread

Suggestion:

 * @summary Verifies whether `QuicSelector` uses virtual threads when
            it is configured using an invalid value

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 115:

> 113:  */
> 114: // -Djava.security.debug=all
> 115: public class H3QuicVTTest implements HttpServerAdapters {

Suggestion:

class H3QuicVTTest implements HttpServerAdapters {

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 132:

> 130:     }
> 131: 
> 132:     static boolean isQuicSelectorThreadVirtual() {

Suggestion:

    private static boolean isQuicSelectorThreadVirtual() {

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 141:

> 139: 
> 140:     @BeforeAll
> 141:     public static void beforeClass() throws Exception {

Suggestion:

    static void beforeClass() throws Exception {

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 155:

> 153: 
> 154:     @AfterAll
> 155:     public static void afterClass() throws Exception {

Suggestion:

    static void afterClass() throws Exception {

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 166:

> 164:      */
> 165:     @Test
> 166:     public void testBasicRequests() throws Exception {

Suggestion:

    void testBasicRequests() throws Exception {

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 199:

> 197:     }
> 198: 
> 199:     void assertSelectorThread(HttpClient client) {

Suggestion:

    private static void assertSelectorThread(HttpClient client) {

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 200:

> 198: 
> 199:     void assertSelectorThread(HttpClient client) {
> 200:         Objects.requireNonNull(client);

I doubt if this is needed.

Suggestion:

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 206:

> 204:                 .map(Thread::getName)
> 205:                 .toList());
> 206:         boolean found = threads.contains(name);

Using thread name for this check looks very fragile. Can we devise a more programmatic method? E.g., ensuring no `StackTraceElement` contains `QuicSelectorThread`?

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 224:

> 222:             System.out.printf("%s: %s%n", status, msg);
> 223:         }
> 224:         Assertions.assertEquals(!isQuicSelectorThreadVirtual(), threads.contains(name), msg);

Suggestion:

        Assertions.assertEquals(!isQuicSelectorThreadVirtual(), found, msg);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487864987
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487758171
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487761972
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487818322
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487846396
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487823188
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487831510
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487834314
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487835902
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487846842
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487848843
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487847519
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487847819
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487847208
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487849223
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487850445
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487801799
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2487764764

From duke at openjdk.org  Tue Nov  4 02:04:14 2025
From: duke at openjdk.org (serhiysachkov)
Date: Tue, 4 Nov 2025 02:04:14 GMT
Subject: Integrated: 8361106: [TEST] com/sun/net/httpserver/Test9.java fails
 with java.nio.file.FileSystemException
In-Reply-To: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
References: <ny27bzBQXVxXRp3jJodW5ZWjJT7k-EeSzgcRZmS_a1k=.46adc34a-68dc-4bd4-ae06-7b2dc0024b56@github.com>
Message-ID: <ETLRKTtivAteNrTkHaS_HdiG6FFPkiWtJgnpZ9imTiQ=.15b7a070-5b36-4966-b646-e0cdaac3268e@github.com>

On Mon, 3 Nov 2025 11:06:35 GMT, serhiysachkov <duke at openjdk.org> wrote:

> [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

This pull request has now been integrated.

Changeset: 576f9694
Author:    Serhiy Sachkov <serhiy.sachkov at oracle.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/576f9694b092f2a11a6a4e5a82c2b0e12203bd9c
Stats:     10 lines in 1 file changed: 2 ins; 5 del; 3 mod

8361106: [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28108

From vyazici at openjdk.org  Tue Nov  4 08:06:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 08:06:47 GMT
Subject: Integrated: 8366575: Remove SDP support
In-Reply-To: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
Message-ID: <TM84-1r5XEo6kZjniboVj0jsAPzq0vL0vJcF6kX1sP0=.a2de2af9-0a09-4876-adee-51d75db28179@github.com>

On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Remove support for [SDP] (Sockets Direct Protocol), which has been obsolete for more than a decade ? see [JDK-8366575] for details. Tier1-2 is clear.
> 
> [SDP]: https://docs.oracle.com/javase/tutorial/sdp/sockets/overview.html
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

This pull request has now been integrated.

Changeset: c1476fca
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1476fca9d7a679d32b7b43956638b845d1027cc
Stats:     732 lines in 13 files changed: 0 ins; 732 del; 0 mod

8366575: Remove SDP support

Reviewed-by: alanb, erikj, jpai, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/28012

From vyazici at openjdk.org  Tue Nov  4 11:00:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 11:00:30 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
Message-ID: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>

`java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.

[JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

-------------

Commit messages:
 - Deprecate `Socket::setPerformancePreferences` and friends for removal

Changes: https://git.openjdk.org/jdk/pull/28129/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8366577
  Stats: 5 lines in 4 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28129/head:pull/28129

PR: https://git.openjdk.org/jdk/pull/28129

From vyazici at openjdk.org  Tue Nov  4 11:04:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 11:04:38 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v6]
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <kPSGt-R9bJg5VwOZhg9LRuRW0Cb2MrslUhHPvWG3i_A=.6a2fe97e-a245-41a1-87fe-6e70f8a085c4@github.com>

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Use `<p id="overflow">` in Javadoc as suggested in reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27973/files
  - new: https://git.openjdk.org/jdk/pull/27973/files/351de8c2..2634e743

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=04-05

  Stats: 27 lines in 1 file changed: 6 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973

PR: https://git.openjdk.org/jdk/pull/27973

From vyazici at openjdk.org  Tue Nov  4 11:04:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 11:04:53 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v5]
In-Reply-To: <MlG8H8xEJIm7jFMmwIFdx0jaZPEY0NLPe76BqlBJ8z4=.5bf85774-3fe4-4d0d-b5ab-ebc9e04ef9c5@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <CbEusg9wiFJ7Dvnlyaq3bIcxTWgIVY60rNfjbfj46NA=.601e6803-33c8-4299-9d37-4c2e0d625d24@github.com>
 <MlG8H8xEJIm7jFMmwIFdx0jaZPEY0NLPe76BqlBJ8z4=.5bf85774-3fe4-4d0d-b5ab-ebc9e04ef9c5@github.com>
Message-ID: <iPZ-zKR547GBgRJdR055-wZ7TQYCfebxy72r7Z_qydI=.04c61abb-9133-4cc2-8402-923813bd1a7e@github.com>

On Mon, 3 Nov 2025 14:30:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into bigDuration
>>  - Merge remote-tracking branch 'upstream/master' into bigDuration
>>  - Simplify exception handling in `Deadline::between`
>>    
>>    Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com>
>>  - Move `delta == 0` in `until()` to the catch block
>>  - Add `DeadlineOverflowTest`
>>  - Fix duration overflows
>>  - Add `DurationOverflowTest`
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 43:
> 
>> 41:  * numeric overflow, {@link #plus(Duration) plus()} will return
>> 42:  * {@link Deadline#MAX} if the provided duration is positive,
>> 43:  * {@link Deadline#MIN} otherwise.
> 
> Instead of speaking of overflow I wonder if we should say:
> 
> 
> Operations that add durations to a {@code Deadline}, whether represented as
> a `Duration` or as a `long` time increment (such as seconds or nano seconds) do
> not throw if the resulting {@code Deadline} would exceed {@link #MAX} or be less
> than {@link #MIN}. Instead, {@code MAX} or {@code MIN} are returned, respectively.

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 43:
> 
>> 41:  * numeric overflow, {@link #plus(Duration) plus()} will return
>> 42:  * {@link Deadline#MAX} if the provided duration is positive,
>> 43:  * {@link Deadline#MIN} otherwise.
> 
> Suggestion:
> 
>  * <p id="overflow"> Operations that add durations to a {@code Deadline}, whether 
>  * represented as a `Duration` or as a `long` time increment (such as seconds or nano
>  * seconds) do not throw on numeric overflow if the resulting {@code Deadline} would 
>  * exceed {@link #MAX} or be less than {@link #MIN}. Instead, {@code MAX} or {@code MIN}
>  * are returned, respectively.

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 61:
> 
>> 59:      * This instance is immutable and unaffected by this method call.
>> 60:      * <p>
>> 61:      * On numeric overflows, this method will return {@link Deadline#MAX} if
> 
> Suggestion:
> 
>      * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 107:
> 
>> 105:      * This instance is immutable and unaffected by this method call.
>> 106:      * <p>
>> 107:      * On numeric overflows, this method will return {@link Deadline#MIN} if
> 
> Suggestion:
> 
>      * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MIN} if

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 131:
> 
>> 129:      * This instance is immutable and unaffected by this method call.
>> 130:      * <p>
>> 131:      * On numeric overflows, this method will return {@link Deadline#MAX} if
> 
> Suggestion:
> 
>      * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 155:
> 
>> 153:      * This instance is immutable and unaffected by this method call.
>> 154:      * <p>
>> 155:      * On numeric overflows, this method will return {@link Deadline#MAX} if
> 
> Suggestion:
> 
>      * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 175:
> 
>> 173:      * This instance is immutable and unaffected by this method call.
>> 174:      * <p>
>> 175:      * On numeric overflows, this method will return {@link Deadline#MAX} if
> 
> Suggestion:
> 
>      * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

Applied in 2634e743025.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 195:
> 
>> 193:      * This instance is immutable and unaffected by this method call.
>> 194:      * <p>
>> 195:      * On numeric overflows, this method will return {@link Deadline#MAX} if
> 
> Suggestion:
> 
>      * On {@linkplain ##overflow numeric overflows}, this method will return {@link Deadline#MAX} if

Applied in 2634e743025.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489992634
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489993179
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489996983
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489994097
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489994864
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489996607
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489995191
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2489995724

From duke at openjdk.org  Tue Nov  4 11:11:26 2025
From: duke at openjdk.org (EunHyunsu)
Date: Tue, 4 Nov 2025 11:11:26 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v3]
In-Reply-To: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
Message-ID: <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>

> Fixes JDK-8371009.
> 
> The synchronous HttpClient example references `request` without defining it.
> This patch adds a minimal HttpRequest initialization immediately before the
> synchronous example (mirroring the asynchronous snippet) so the example
> compiles and runs as-is.

EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8371009: fix indent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28084/files
  - new: https://git.openjdk.org/jdk/pull/28084/files/0c799d0e..34f8d04b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28084&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28084&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28084/head:pull/28084

PR: https://git.openjdk.org/jdk/pull/28084

From duke at openjdk.org  Tue Nov  4 11:21:56 2025
From: duke at openjdk.org (EunHyunsu)
Date: Tue, 4 Nov 2025 11:21:56 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v2]
In-Reply-To: <DqyOYaJtgK-Zi-PX1QHnuvbTYrJ3WxojeXzTCLDQBVY=.258e0580-379a-4a69-b15c-1950727a867c@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <BTLPkaNof7Zm87wnss_ebiBA9tV0WZuGPL8tAwCYMaQ=.bcac1f3e-570d-4754-a2bc-3eaab9f1b298@github.com>
 <h3mgsmQ3jilplz911FtQhhQxeOOgQgb-BKphs6SIolk=.50d1bf66-8d3b-4323-bf9a-d568dc5cb971@github.com>
 <DqyOYaJtgK-Zi-PX1QHnuvbTYrJ3WxojeXzTCLDQBVY=.258e0580-379a-4a69-b15c-1950727a867c@github.com>
Message-ID: <4aBaKVMNRyafRsxnG2VhVN2dqVcGxByfz7xJbMBm7s4=.1e6cf996-c5f7-425f-86cd-1d5c5fd329bc@github.com>

On Mon, 3 Nov 2025 16:08:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> > Upon checking again, I noticed that the asynchronous example is indented slightly more than the synchronous one.
> > It appears that this difference already existed prior to my patch.
> > Just wanted to confirm whether this is intentional or if we should align the indentation for consistency.
> 
> It looks like it's only the first line in the asynchronous example that is misaligned. It would be good to fix it along in this PR. Thanks for catching this.

Thanks! The indentation fix has been included in the latest commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3485437784

From duke at openjdk.org  Tue Nov  4 11:23:17 2025
From: duke at openjdk.org (EunHyunsu)
Date: Tue, 4 Nov 2025 11:23:17 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v3]
In-Reply-To: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
Message-ID: <BMonHPc58Oza6ljpaqNaDHFmssegfNvGZW8qpWDsbgA=.079d747b-993d-4b79-a48f-6502332bffc4@github.com>

> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
> 
> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
> 
> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
> 
> Currently, only POST(), PUT(), and method() include these messages.
> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
> I would like to discuss whether adding consistent messages to those methods would be beneficial,
> and whether the current wording "BodyPublisher must not be null" feels appropriate.

EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:

  8371091: Add testNullMessages() to HttpRequestBuilderTest

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28103/files
  - new: https://git.openjdk.org/jdk/pull/28103/files/24ecfc3b..b90837b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=01-02

  Stats: 526 lines in 2 files changed: 36 ins; 59 del; 431 mod
  Patch: https://git.openjdk.org/jdk/pull/28103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28103/head:pull/28103

PR: https://git.openjdk.org/jdk/pull/28103

From duke at openjdk.org  Tue Nov  4 11:33:45 2025
From: duke at openjdk.org (Peyang)
Date: Tue, 4 Nov 2025 11:33:45 GMT
Subject: RFR: 8371092: NullPointerException in
 AltServiceUsageTest.afterClass() test
In-Reply-To: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
References: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
Message-ID: <ZUdXLRBj98nQQ_3GOfwPsVB9EVDNiT22PjBs9HQjKxQ=.a4e57297-acee-48d1-a982-092bf18a4d49@github.com>

On Sun, 2 Nov 2025 14:09:28 GMT, Peyang <duke at openjdk.org> wrote:

> - Add `safeClose(DatagramChannel)` to close udpNotResponding safely.
> - Null-check and exception handling unified with `safeStop()`.
> - Ensures test cleanup never fails due to uninitialized or problematic channel.

Thanks for your review.
I've run the test locally and confirmed it passes successfully.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28104#issuecomment-3485501240

From duke at openjdk.org  Tue Nov  4 11:33:46 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Nov 2025 11:33:46 GMT
Subject: RFR: 8371092: NullPointerException in
 AltServiceUsageTest.afterClass() test
In-Reply-To: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
References: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
Message-ID: <UptPcS96YFUH1cOgoSoJrHhSWh0i2VDI8XfbEAu4vd4=.46be132f-bf8d-4f4b-bc7f-e75533cbf949@github.com>

On Sun, 2 Nov 2025 14:09:28 GMT, Peyang <duke at openjdk.org> wrote:

> - Add `safeClose(DatagramChannel)` to close udpNotResponding safely.
> - Null-check and exception handling unified with `safeStop()`.
> - Ensures test cleanup never fails due to uninitialized or problematic channel.

@PeyaPeyaPeyang 
Your change (at version c069042f507e1cccf1f6ad101f73cf28d15dd238) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28104#issuecomment-3485514508

From duke at openjdk.org  Tue Nov  4 11:37:13 2025
From: duke at openjdk.org (EunHyunsu)
Date: Tue, 4 Nov 2025 11:37:13 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v4]
In-Reply-To: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
Message-ID: <LcMIBTb-AwN67zFLEn93RAxoOUG6GI0Q7Vgi4vSa9us=.81088c86-8e0a-4bff-bdcd-bfb0d7b7ba3e@github.com>

> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
> 
> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
> 
> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
> 
> Currently, only POST(), PUT(), and method() include these messages.
> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
> I would like to discuss whether adding consistent messages to those methods would be beneficial,
> and whether the current wording "BodyPublisher must not be null" feels appropriate.

EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:

  8371091: Add testNullMessages() to HttpRequestBuilderTest and fix whitespaces error

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28103/files
  - new: https://git.openjdk.org/jdk/pull/28103/files/b90837b0..f26cc336

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28103&range=02-03

  Stats: 468 lines in 1 file changed: 1 ins; 0 del; 467 mod
  Patch: https://git.openjdk.org/jdk/pull/28103.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28103/head:pull/28103

PR: https://git.openjdk.org/jdk/pull/28103

From duke at openjdk.org  Tue Nov  4 11:37:15 2025
From: duke at openjdk.org (EunHyunsu)
Date: Tue, 4 Nov 2025 11:37:15 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v2]
In-Reply-To: <5B3wKzsQnst9zPxsqwsVI21oYyZ3hU4wQhZ_QtteFSc=.9e0edcdb-db86-423a-ad8a-45f7be03c178@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <uRa8ZRfCk76iHQQt-T6hqtMy48c73FuMtJr-S6A7drE=.f9197dc1-40fa-4946-9a3c-2db6545372bf@github.com>
 <IhcudRt2dsGsz-fbG40QtgXmteeytu-vdI7czCnovbk=.c7607f3e-952c-44e4-b403-071b7ff67bf0@github.com>
 <u054sSqjsouXL2DvNKn1XzjsmtepvOXOpCxAnHEn-HI=.336208d1-1217-429b-9fd8-62254780a24d@github.com>
 <5B3wKzsQnst9zPxsqwsVI21oYyZ3hU4wQhZ_QtteFSc=.9e0edcdb-db86-423a-ad8a-45f7be03c178@github.com>
Message-ID: <srWNwsga_8fGvkeEtvtc_kF_bpRxoTRrH3i-1NwHImc=.173ea70c-6292-4842-b51e-32dfa22ed459@github.com>

On Mon, 3 Nov 2025 16:13:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > would it make sense to add a small new test method,
> > say testNullMessages(), in the same class to verify the exception messages specifically?
> 
> I think that should be OK. It doesn't have to be too complicated/generic either, as long as it tests these specific method calls.

Thanks for confirming! I?ll add a straightforward testNullMessages() method in the same class to verify those specific calls.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28103#issuecomment-3485522603

From duke at openjdk.org  Tue Nov  4 13:34:42 2025
From: duke at openjdk.org (Peyang)
Date: Tue, 4 Nov 2025 13:34:42 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v10]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <WWCCbKmW4Oc3CSFG5xPlllRpEe6dzg4NZ-NXCIz3BCo=.08cba8db-f803-4fa1-ad24-38683907cf4a@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request incrementally with one additional commit since the last revision:

  Implement range normalization for overlapping and contiguous HTTP Range headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28021/files
  - new: https://git.openjdk.org/jdk/pull/28021/files/83b1a2b4..f0c94e81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=08-09

  Stats: 62 lines in 3 files changed: 46 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From duke at openjdk.org  Tue Nov  4 13:40:39 2025
From: duke at openjdk.org (Peyang)
Date: Tue, 4 Nov 2025 13:40:39 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v6]
In-Reply-To: <avgqYYwPHiF3k9GuzYgaBcp3iChNEWOWD6U7P3lYANg=.28dd810d-b1bd-494f-9c54-1f1e7ccd2811@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <c7zlO6MqbjqGrgnK8PGItTF_yyetlwZcxWzr_8eNY8s=.634c1bab-cf8c-4522-8193-4f66e08eee81@github.com>
 <sUPqefqumSJvgaP9K2CSY1TW2uSizx1T8VIu5GhnhkY=.e04af8b5-1927-4ad9-875c-f38b4de78368@github.com>
 <j8lzEllemz1WD1FIVOjp0HnzVrTbBl44GclsSMaj5EI=.782e21d0-063b-4294-b227-1682b4cddb63@github.com>
 <9dX_Pl6xcwpO1YgLTj_L3qkGj_Dgrbo3VS3iiztbejo=.bdd88636-83dd-44cf-8edc-c4f8fcfa1ca4@github.com>
 <fdM86qDcaEXxyfqM6UT-7Pjz73qg_0T79xTaqf4vKrY=.d0784c46-5cf7-4337-bf8a-2dc478a8ab80@github.com>
 <avgqYYwPHiF3k9GuzYgaBcp3iChNEWOWD6U7P3lYANg=.28dd810d-b1bd-494f-9c54-1f1e7ccd2811@github.com>
Message-ID: <SS-pV5s0gM3gF1ItL9OxQqArjLnmu9GfjkI2MZc0lX8=.46ecb63d-8b66-41bb-a16c-61004cea8a9e@github.com>

On Mon, 3 Nov 2025 10:10:50 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> The `ranges` list in the arguments is constructed so that each range's end option does not exceed the file size: if a requested range goes beyond the file lengh, it is clamped accordingly.
>> Therefore, I don't think any foundamental change is needed here.
>> 
>> We could add an `assert` (and a comment) to make this assumption explict, or possibly throw an IOE in case the file was truncated or modified during sending.
>
> I definitely don't want code that allows a `Content-Range: bytes 1000-2000` to be written and treated as normal if the file hits EOF 10 bytes short. Even if the situation cannot arise due to higher level checks, I'd like to see IOE thrown rather than breaking from the loop.

Thanks for the clarification.
I've updated the implementation accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2490551797

From jpai at openjdk.org  Tue Nov  4 13:50:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Nov 2025 13:50:21 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <iAgN-E1GT697P-DU_Rl2G2rkoehYzZ7seX7eB88rTco=.6ddf7a7b-7d12-4bdd-b690-c8f339df0f15@github.com>

On Tue, 4 Nov 2025 10:53:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28129#pullrequestreview-3416562326

From alanb at openjdk.org  Tue Nov  4 13:58:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 13:58:46 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <cceeQg1Sxyma2netm_p0KiPT8KqPw07spEK2TDBjnk8=.39e1c74d-17d7-469b-979f-3b1293b4bbeb@github.com>

On Tue, 4 Nov 2025 10:53:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

src/java.base/share/classes/java/net/ServerSocket.java line 951:

> 949:      * @since 1.5
> 950:      */
> 951:     @Deprecated(since = "26", forRemoval = true)

Are you planning to add a `@deprecated` comment to these methods?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2490619726

From duke at openjdk.org  Tue Nov  4 14:08:25 2025
From: duke at openjdk.org (Peyang)
Date: Tue, 4 Nov 2025 14:08:25 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v6]
In-Reply-To: <0v49K19iLf33_xI6mfN5l3BziRkCPUqeIoiyCp8lRa0=.2230a7d3-7ebc-44e6-9e08-d2d5422bdfc7@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <c7zlO6MqbjqGrgnK8PGItTF_yyetlwZcxWzr_8eNY8s=.634c1bab-cf8c-4522-8193-4f66e08eee81@github.com>
 <W7rjnmIDYpMVIKN_cRcN5WNP072ZeEWqBDbPd9XlfJo=.6082177d-b2a6-4c0a-8fa7-f4039cb6de1c@github.com>
 <Ipgubm_0ANsn4hZjpItn72Nzg11iIubInheuhVA8Qc0=.499fa9f3-8408-4d05-9fb6-82056b4443d2@github.com>
 <aVV6LTjo5_plwqXnUqSleXBQhCy2_wJBUnckM5GM3H4=.3589fad9-7f8f-429d-8519-5447b2e7d5eb@github.com>
 <MNM8xdtyCxl3JauOI9q3biGtQcis7fPLITedGyqvWhk=.852dedfe-248c-420a-80b8-a89d4465875c@github.com>
 <0v49K19iLf33_xI6mfN5l3BziRkCPUqeIoiyCp8lRa0=.2230a7d3-7ebc-44e6-9e08-d2d5422bdfc7@github.com>
Message-ID: <moP4Z6V4ufqXBLDWAjUyjLCQTU5uh5Jm1JPQqldDat4=.e3a5a93d-d0ec-4e62-b368-48a5f9237813@github.com>

On Mon, 3 Nov 2025 15:58:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I implemented a check that validates whether the ranges are in ascendnig order and non-overlapping, returning an error if they are not.
>> However, I have some concerns: this restriction might be too strict.
>> 
>> Instead of outright rejecting requests with overlapping or unsorted ranges, what if the server simply combines overlapping ranges and sorts them before returning?
>> According to [RFC 7233 ?15.3.7.2](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7.2-4):
>>> When multiple ranges are requested, a server **MAY** coalesce any of the ranges that overlap, or that are separated by a gap that is smaller than the overhead of sending multiple parts, regardless of the order in which the corresponding range-spec appeared in the received [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header field.  
>> 
>> In other words, rather than strictly validating and rejecting, we could treat this as an efficiency optimization on the server side. I think this approach would be more practical. I?d like to hear your thoughts on this.
>
> That would be fine too.

I updated the implementation to merge overlapping or unsorted ranges and sort them before returning, instead of rejecting.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2490654650

From duke at openjdk.org  Tue Nov  4 14:08:24 2025
From: duke at openjdk.org (Peyang)
Date: Tue, 4 Nov 2025 14:08:24 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v11]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <kw6hDdbK8XF5CCpK8oJRIWqQ9hfVLz27lpS9GNq1Wxg=.b00147d6-74a7-42de-9dd3-84515d291e8b@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request incrementally with one additional commit since the last revision:

  Throw IOException on unexpected EOF while reading file in FileServerHandler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28021/files
  - new: https://git.openjdk.org/jdk/pull/28021/files/f0c94e81..2540945c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From michaelm at openjdk.org  Tue Nov  4 14:17:44 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 4 Nov 2025 14:17:44 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange usability
Message-ID: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>

I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.

I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.

Thanks,
Michael

-------------

Commit messages:
 - implementation and test
 - Merge branch 'master' into httpserver-8368955
 - doc update

Changes: https://git.openjdk.org/jdk/pull/28132/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331195
  Stats: 60 lines in 9 files changed: 29 ins; 3 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From dfuchs at openjdk.org  Tue Nov  4 14:53:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 14:53:18 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v2]
In-Reply-To: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
Message-ID: <3c3Z9mIQqMhuJ4JPwCQIgLOa1t_SMqNoHhfLv-tAuvc=.f7a1d132-2015-4bab-8219-ef2914e0a9ef@github.com>

> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
> 
> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.

Daniel Fuchs has updated the pull request incrementally with two additional commits since the last revision:

 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27827/files
  - new: https://git.openjdk.org/jdk/pull/27827/files/0602a405..8a53537c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27827.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27827/head:pull/27827

PR: https://git.openjdk.org/jdk/pull/27827

From duke at openjdk.org  Tue Nov  4 14:53:24 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Tue, 4 Nov 2025 14:53:24 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode
Message-ID: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>

Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.

**Problem**
Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.

**Fix**
- `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
- `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
- No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).

**Compatibility**
Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.

**Testing**
New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

-------------

Commit messages:
 - 8367049: URL.openConnection throws StringIndexOutOfBoundsException in avm mode

Changes: https://git.openjdk.org/jdk/pull/27896/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367049
  Stats: 81 lines in 3 files changed: 81 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From alanb at openjdk.org  Tue Nov  4 15:00:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 15:00:05 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <3S8LhaxwiUJhygb9PoiMlG42hoBYPxnPfzDzjgAm-hg=.f0078f2d-3393-42a8-b0e5-9f7dd191c61f@github.com>

On Mon, 20 Oct 2025 12:12:56 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

The title on the JBS issue and PR is a bit confusing. Opening a URL connection shouldn't use URLPermission anymore so I think the issue (in main line) is really with code that uses the deprecated URLPermission class directly. Would it be possible to confirm this, and if confirmed, can the JBS issue be renamed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27896#issuecomment-3486404798

From dfuchs at openjdk.org  Tue Nov  4 15:02:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:02:58 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v3]
In-Reply-To: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
Message-ID: <e_Cfz6RvwCFW7Kmo8l4M3UUaIKCFw5r0KvOYApx7G_A=.7a8318f9-016c-4e8c-98ae-f875913aaad7@github.com>

> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
> 
> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.

Daniel Fuchs has updated the pull request incrementally with 11 additional commits since the last revision:

 - Apply suggestion from @dfuch
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - ... and 1 more: https://git.openjdk.org/jdk/compare/8a53537c...3a0b2a69

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27827/files
  - new: https://git.openjdk.org/jdk/pull/27827/files/8a53537c..3a0b2a69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=01-02

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27827.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27827/head:pull/27827

PR: https://git.openjdk.org/jdk/pull/27827

From dfuchs at openjdk.org  Tue Nov  4 15:03:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:03:04 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v3]
In-Reply-To: <IiOIdIInKhx-4Sr94StYcVgtvGLFTOtBk5BI-i569QA=.f962f348-e168-4518-9e20-195786108e30@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
 <IiOIdIInKhx-4Sr94StYcVgtvGLFTOtBk5BI-i569QA=.f962f348-e168-4518-9e20-195786108e30@github.com>
Message-ID: <I3qaRDrkkbCgk00jvwy3B4kNKXSTNzkQkfSNisNvVd8=.32897139-f38d-4e43-b6b0-c728f411708b@github.com>

On Mon, 3 Nov 2025 21:03:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with 11 additional commits since the last revision:
>> 
>>  - Apply suggestion from @dfuch
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8a53537c...3a0b2a69
>
> test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 57:
> 
>> 55:  * @library /test/lib /test/jdk/java/net/httpclient/lib
>> 56:  * @build jdk.test.lib.net.SimpleSSLContext
>> 57:  *        jdk.httpclient.test.lib.common.HttpServerAdapters
> 
> @sormuras, in this JUnit test, given these `@build` classes are already included in `@library`, do we still need this explicit `@build`?

All our tests do that and we had a few iterations before finding something that worked reliably. My2c is don't change it unless it starts causing trouble.

> test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 206:
> 
>> 204:                 .map(Thread::getName)
>> 205:                 .toList());
>> 206:         boolean found = threads.contains(name);
> 
> Using thread name for this check looks very fragile. Can we devise a more programmatic method? E.g., ensuring no `StackTraceElement` contains `QuicSelectorThread`?

It's a bit fragile but if we change the name of the thread we will just have to change the test. Looking through the stack trace elements could be more fragile.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2490834901
PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2490818481

From dfuchs at openjdk.org  Tue Nov  4 15:03:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:03:00 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v3]
In-Reply-To: <e_Cfz6RvwCFW7Kmo8l4M3UUaIKCFw5r0KvOYApx7G_A=.7a8318f9-016c-4e8c-98ae-f875913aaad7@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
 <e_Cfz6RvwCFW7Kmo8l4M3UUaIKCFw5r0KvOYApx7G_A=.7a8318f9-016c-4e8c-98ae-f875913aaad7@github.com>
Message-ID: <57cho0KYJQei2tcO-N2hkR6qT9BGS8OtxmmqgmLHLgc=.706d4797-cde8-40e6-970f-b924ed5dc76d@github.com>

On Tue, 4 Nov 2025 15:00:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
>> 
>> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.
>
> Daniel Fuchs has updated the pull request incrementally with 11 additional commits since the last revision:
> 
>  - Apply suggestion from @dfuch
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8a53537c...3a0b2a69

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicEndpoint.java line 148:

> 146:         MAX_BUFFERED_LOW = maxBufferLow;
> 147:         String useVtForSelector =
> 148:                 System.getProperty("jdk.internal.httpclient.quic.useVTForSelector", "default");

Suggestion:

                System.getProperty("jdk.internal.httpclient.quic.selector.useVirtualThreads", "default");

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2490853880

From dfuchs at openjdk.org  Tue Nov  4 15:16:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:16:13 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v4]
In-Reply-To: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
Message-ID: <eeJdtLMXD4ek0ex3wC19FXuT1AZsoV-GtqJvAnz57UQ=.d0e1ccc1-a305-41cf-bc32-3af396ec5ea7@github.com>

> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
> 
> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.

Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:

 - Apply suggestion from @vy
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Apply suggestion from @vy
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update the test to match the new property name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27827/files
  - new: https://git.openjdk.org/jdk/pull/27827/files/3a0b2a69..f5a05218

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27827&range=02-03

  Stats: 13 lines in 1 file changed: 0 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/27827.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27827/head:pull/27827

PR: https://git.openjdk.org/jdk/pull/27827

From dfuchs at openjdk.org  Tue Nov  4 15:16:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:16:15 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v4]
In-Reply-To: <IiOIdIInKhx-4Sr94StYcVgtvGLFTOtBk5BI-i569QA=.f962f348-e168-4518-9e20-195786108e30@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
 <IiOIdIInKhx-4Sr94StYcVgtvGLFTOtBk5BI-i569QA=.f962f348-e168-4518-9e20-195786108e30@github.com>
Message-ID: <Bf2z5ohspsrw1I0H00kzTPNyxO8pVmKaEBRR21Jcsew=.978365cb-5da7-4376-a038-cbc565482b77@github.com>

On Mon, 3 Nov 2025 20:24:59 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Apply suggestion from @vy
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Apply suggestion from @vy
>>    
>>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>>  - Update the test to match the new property name
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicSelector.java line 510:
> 
>> 508:     }
>> 509: 
>> 510:     private record QuicSelectorThread(Thread thread) {
> 
> AFAICS, all methods ? `start()`, `join()`, `ofPlatform()`, `ofVirtual()`, and `of()` ? can be `private`.

You're not wrong, but I prefer to keep them package to distinguish betwen methods that should only be called from with the record class itself as opposed to methods that are designed to be called from the enclosing class, or other classes in the nest.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27827#discussion_r2490903516

From dfuchs at openjdk.org  Tue Nov  4 15:36:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:36:10 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v6]
In-Reply-To: <kPSGt-R9bJg5VwOZhg9LRuRW0Cb2MrslUhHPvWG3i_A=.6a2fe97e-a245-41a1-87fe-6e70f8a085c4@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <kPSGt-R9bJg5VwOZhg9LRuRW0Cb2MrslUhHPvWG3i_A=.6a2fe97e-a245-41a1-87fe-6e70f8a085c4@github.com>
Message-ID: <xfn_Qnz8OM1P9zVS0XW_peVfS0-ASWoQ6Qdg5iSrBd8=.715c9e74-adfa-4ea2-9ae0-96d9c348229e@github.com>

On Tue, 4 Nov 2025 11:04:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `<p id="overflow">` in Javadoc as suggested in reviews

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 39:

> 37:  * This class is immutable and thread-safe.
> 38:  * <p id="overflow">
> 39:  * Operations that add durations to a {@code Deadline}, whether represented as a

Suggestion:

 * Operations that add or subtract durations to a {@code Deadline}, whether represented as a

src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 43:

> 41:  * nanoseconds) do not throw on numeric overflow if the resulting
> 42:  * {@code Deadline} would exceed {@link #MAX} or be less than {@link #MIN}.
> 43:  * Instead, {@code MAX} or {@code MIN} is returned, respectively.

Suggestion:

 * Instead, {@code MAX} or {@code MIN} is returned, respectively.
 * Similarly, methods that return a duration as a {@code long} will either return 
 * {@link Long#MAX_VALUE} or {@link Long#MIN_VALUE} if the returned quantity would 
 * exceed the capacity of a {@code long}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2490973411
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2490983462

From dfuchs at openjdk.org  Tue Nov  4 15:38:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 15:38:05 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v3]
In-Reply-To: <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>
Message-ID: <T594QDjBEIMzXT0EFB4EhVDSgFY5ZcM9gymmqv_hUtg=.2f261a4e-8402-470e-acb7-39dacc8725ef@github.com>

On Tue, 4 Nov 2025 11:11:26 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> Fixes JDK-8371009.
>> 
>> The synchronous HttpClient example references `request` without defining it.
>> This patch adds a minimal HttpRequest initialization immediately before the
>> synchronous example (mirroring the asynchronous snippet) so the example
>> compiles and runs as-is.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8371009: fix indent

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28084#pullrequestreview-3417147285

From dfuchs at openjdk.org  Tue Nov  4 16:05:20 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 16:05:20 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <rXLiodK-KbAwORZ5oyjYDZlKOwJANSQ6-rX69ebzPdE=.11aa8df0-a38c-4e47-8fea-a15de3fb7fa3@github.com>

On Tue, 4 Nov 2025 14:10:14 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

This is a good idea, but it kind of hides the fact that passing 0 may not do what you think it does. 

Typically the pitfall is to assume that if you have an array of bytes then you can can call `sendResponseHeaders` with the array length. The API doc of `sendResponseHeaders` should probably make it clear that 0 is a special value, and that `RSPBODY_CHUNKED` is 0. 

In addition I would suggest adding code snipets showing both cases (one using a byte array and passing `bytes.length == 0 ? RSPBODY_EMPTY : bytes.length` and the other using `RSPBODY_CHUNKED` with e.g. transferring the content of an `InputStream`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3486767513

From dfuchs at openjdk.org  Tue Nov  4 16:11:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 16:11:29 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <lVKdn0NHjVGPutGGbwbB-8UTffZRxfaqV4XcrmYGh_Y=.7f6ab799-15de-4801-b592-9ad409fa2b01@github.com>

On Mon, 20 Oct 2025 12:12:56 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

test/jdk/java/net/URLPermission/EmptyAuthorityTest.java line 69:

> 67:         new URLPermission(url); // should not throw
> 68:     }
> 69: }

Please add a new line at the end of the file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27896#discussion_r2491130629

From duke at openjdk.org  Tue Nov  4 16:11:39 2025
From: duke at openjdk.org (Peyang)
Date: Tue, 4 Nov 2025 16:11:39 GMT
Subject: Integrated: 8371092: NullPointerException in
 AltServiceUsageTest.afterClass() test
In-Reply-To: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
References: <Qm2MRKr0jiTcJZmNiDa292DlWYht6Q7AaG_pieMkMoM=.6b651437-61ae-4a88-bd67-7d4adf683b85@github.com>
Message-ID: <u6Pv6C5jtGgXOaVm3_QeRRpc6-oFWzzByTYqm7gfk70=.799ce497-ccfd-4326-b704-2a5349b4842a@github.com>

On Sun, 2 Nov 2025 14:09:28 GMT, Peyang <duke at openjdk.org> wrote:

> - Add `safeClose(DatagramChannel)` to close udpNotResponding safely.
> - Null-check and exception handling unified with `safeStop()`.
> - Ensures test cleanup never fails due to uninitialized or problematic channel.

This pull request has now been integrated.

Changeset: 2f455ed1
Author:    Peyang <peyang at peya.tokyo>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f455ed146ff2e56da4532e9430e4c85ca9497ad
Stats:     14 lines in 1 file changed: 13 ins; 0 del; 1 mod

8371092: NullPointerException in AltServiceUsageTest.afterClass() test

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28104

From coffeys at openjdk.org  Tue Nov  4 16:22:31 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 4 Nov 2025 16:22:31 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <cnkQv6UnRtlyUl8uihwaZtByunuw57fDFxG7zGwwiv8=.4abe43e2-a535-44d3-bdc5-23ab42533801@github.com>

On Mon, 20 Oct 2025 12:12:56 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Looks fine to me

-------------

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27896#pullrequestreview-3417395498

From michaelm at openjdk.org  Tue Nov  4 16:26:55 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 4 Nov 2025 16:26:55 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability
In-Reply-To: <rXLiodK-KbAwORZ5oyjYDZlKOwJANSQ6-rX69ebzPdE=.11aa8df0-a38c-4e47-8fea-a15de3fb7fa3@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <rXLiodK-KbAwORZ5oyjYDZlKOwJANSQ6-rX69ebzPdE=.11aa8df0-a38c-4e47-8fea-a15de3fb7fa3@github.com>
Message-ID: <eFBaLQWHIhDDbccaMsrbYMjmt_87QLFy7w3pYz1SPn4=.684809ea-83d5-44b7-915e-c39ea17387fe@github.com>

On Tue, 4 Nov 2025 16:02:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is a good idea, but it kind of hides the fact that passing 0 may not do what you think it does.
> 
> Typically the pitfall is to assume that if you have an array of bytes then you can can call `sendResponseHeaders` with the array length. The API doc of `sendResponseHeaders` should probably make it clear that 0 is a special value, and that `RSPBODY_CHUNKED` is 0.
> 

Actually, that case is not so bad. What happens is that chunked encoding is selected but the response body
content is empty as intended, and it should work. But, maybe we should still highlight it anyway.

> In addition I would suggest adding code snipets showing both cases (one using a byte array and passing `bytes.length == 0 ? RSPBODY_EMPTY : bytes.length` and the other using `RSPBODY_CHUNKED` with e.g. transferring the content of an `InputStream`.

The worse case is expecting a negative value to mean an indefinite (chunked encoded) length. You definitely don't get what you expect in that case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3486869930

From dfuchs at openjdk.org  Tue Nov  4 17:08:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 17:08:47 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <a3SLU7XamqrsReshGaear3YMr2ELnd7Z3CL_sfWiawA=.8fab59d1-09aa-4326-a115-983fdbaeeff3@github.com>

On Mon, 20 Oct 2025 12:12:56 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

I agree with Alan that we should update the JBS issue title to match what is being fixed.
`URL.openConnection` does not throw in JDK 24 and later. `URLPermission` still does.
Otherwise the proposed fix looks reasonable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27896#issuecomment-3487087557

From vyazici at openjdk.org  Tue Nov  4 17:32:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 17:32:48 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Improve Javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28129/files
  - new: https://git.openjdk.org/jdk/pull/28129/files/50826c3e..41c918cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28129&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28129&range=00-01

  Stats: 9 lines in 3 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28129/head:pull/28129

PR: https://git.openjdk.org/jdk/pull/28129

From vyazici at openjdk.org  Tue Nov  4 17:32:50 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 17:32:50 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <cceeQg1Sxyma2netm_p0KiPT8KqPw07spEK2TDBjnk8=.39e1c74d-17d7-469b-979f-3b1293b4bbeb@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <cceeQg1Sxyma2netm_p0KiPT8KqPw07spEK2TDBjnk8=.39e1c74d-17d7-469b-979f-3b1293b4bbeb@github.com>
Message-ID: <q0wItBUZg8NM8m_bhwPsWhlVknmX-udt4yDtafAKrgQ=.44531425-79ab-4e30-bbe2-4c743e363626@github.com>

On Tue, 4 Nov 2025 13:55:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Javadoc
>
> src/java.base/share/classes/java/net/ServerSocket.java line 951:
> 
>> 949:      * @since 1.5
>> 950:      */
>> 951:     @Deprecated(since = "26", forRemoval = true)
> 
> Are you planning to add a `@deprecated` comment to these methods?

I was not intending to, but added in 41c918cfa60 after your nudge.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2491445107

From duke at openjdk.org  Tue Nov  4 17:37:24 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Tue, 4 Nov 2025 17:37:24 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode [v2]
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <JM4m7lZFzMR4f14fwZHH2yxQ20GQY6TvPsRIHLAU9q4=.d8b178f1-cc4d-403b-9992-45940d86ccc4@github.com>

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing newline at end of EmptyAuthorityTest.java
  
  Add missing newline at the end of the file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27896/files
  - new: https://git.openjdk.org/jdk/pull/27896/files/1d28e6fd..a4089913

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From duke at openjdk.org  Tue Nov  4 17:37:26 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Tue, 4 Nov 2025 17:37:26 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode
In-Reply-To: <3S8LhaxwiUJhygb9PoiMlG42hoBYPxnPfzDzjgAm-hg=.f0078f2d-3393-42a8-b0e5-9f7dd191c61f@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <3S8LhaxwiUJhygb9PoiMlG42hoBYPxnPfzDzjgAm-hg=.f0078f2d-3393-42a8-b0e5-9f7dd191c61f@github.com>
Message-ID: <vY4WQ4dghL74MOYB-hsL3FbqwD9t0RgGoUODoZsGn80=.b68eb521-e597-4df1-ba26-b109bb7eb003@github.com>

On Tue, 4 Nov 2025 14:56:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The title on the JBS issue and PR is a bit confusing. Opening a URL connection shouldn't use URLPermission anymore so I think the issue (in main line) is really with code that uses the deprecated URLPermission class directly. Would it be possible to confirm this, and if confirmed, can the JBS issue be renamed?

Thank you for your feedback. The issue was reported specifically for JDK 17, so the current JBS issue title accurately reflects the context and version concerned. While the root cause is with `URLPermission` and `HostPortrange` (which still exist in the main line) the title needs to remain as is to properly indicate that this is a JDK 17 issue.

The planned approach is to address and fix the issue in the main line first. Once resolved, the fix will then be backported to JDK 17 and other affected releases.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27896#issuecomment-3487242775

From alanb at openjdk.org  Tue Nov  4 17:53:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 17:53:39 GMT
Subject: RFR: 8367049: URL.openConnection throws
 StringIndexOutOfBoundsException in avm mode [v2]
In-Reply-To: <JM4m7lZFzMR4f14fwZHH2yxQ20GQY6TvPsRIHLAU9q4=.d8b178f1-cc4d-403b-9992-45940d86ccc4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <JM4m7lZFzMR4f14fwZHH2yxQ20GQY6TvPsRIHLAU9q4=.d8b178f1-cc4d-403b-9992-45940d86ccc4@github.com>
Message-ID: <S9781w2ROKbpFNHEhEbTwAD-LnCqsT6fszU-GkrQfCg=.df2ac89d-0982-467b-beb2-605e036a9df9@github.com>

On Tue, 4 Nov 2025 17:37:24 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing newline at end of EmptyAuthorityTest.java
>   
>   Add missing newline at the end of the file.

I've renamed the JBS issue as it is too confusing to target main line with commit suggestion URLConnection then it's an issue with the deprecated URLPermission.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27896#issuecomment-3487341152

From dfuchs at openjdk.org  Tue Nov  4 18:01:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 18:01:36 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v8]
In-Reply-To: <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>
Message-ID: <5f7komVMjMAg3Dck_trHLmn-gUOJp3nOCFlzkPa9NJM=.76449183-c2e4-4b7a-ae5b-c71c9d954a51@github.com>

On Mon, 3 Nov 2025 14:36:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Shorten `TimeoutResponseTestSupport` using imports
>  - Make `MultiExchange::cancelTimer` package-private
>  - Merge remote-tracking branch 'upstream/master' into respBodyTime
>  - Simplify Javadoc
>  - Merge remote-tracking branch 'upstream/master' into respBodyTime
>  - Improve `HttpBodySubscriberWrapper::onTermination` JavaDoc
>  - Mark `SubscriptionWrapper` as `final`
>  - Replace wrapper's `preTerminationCallback` argument with a method to be extended
>  - Fix `HttpClient` doc typo
>  - Invoke `preTerminationCallback` at `cancel()` too
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/ef464d69...55396846

src/java.net.http/share/classes/java/net/http/WebSocket.java line 151:

> 149:          * moment a connection is requested until it is established. The elapsed
> 150:          * time includes any SSL/TLS handshake.
> 151:          *

This change should probably be  ammended. 
The connectionTimeout for websocket is set as the request timeout for the HTTP upgrade request to websocket.
So it includes both the handshake and the 101 response.
Now I wonder if we are missing something that will cancel the timer when handing the connection off to WebSocket. It would be good to double check. We had no failing tests so maybe this is properly handled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2491576541

From dfuchs at openjdk.org  Tue Nov  4 18:10:42 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 18:10:42 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v8]
In-Reply-To: <5f7komVMjMAg3Dck_trHLmn-gUOJp3nOCFlzkPa9NJM=.76449183-c2e4-4b7a-ae5b-c71c9d954a51@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>
 <5f7komVMjMAg3Dck_trHLmn-gUOJp3nOCFlzkPa9NJM=.76449183-c2e4-4b7a-ae5b-c71c9d954a51@github.com>
Message-ID: <izz61VkzwQHYZX0RiMsn1FKg0CJFrb9HVrhVBGdVRYc=.7ce26430-0d6f-41d6-8ca7-d85fb152e05b@github.com>

On Tue, 4 Nov 2025 17:58:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
>> 
>>  - Shorten `TimeoutResponseTestSupport` using imports
>>  - Make `MultiExchange::cancelTimer` package-private
>>  - Merge remote-tracking branch 'upstream/master' into respBodyTime
>>  - Simplify Javadoc
>>  - Merge remote-tracking branch 'upstream/master' into respBodyTime
>>  - Improve `HttpBodySubscriberWrapper::onTermination` JavaDoc
>>  - Mark `SubscriptionWrapper` as `final`
>>  - Replace wrapper's `preTerminationCallback` argument with a method to be extended
>>  - Fix `HttpClient` doc typo
>>  - Invoke `preTerminationCallback` at `cancel()` too
>>  - ... and 21 more: https://git.openjdk.org/jdk/compare/ef464d69...55396846
>
> src/java.net.http/share/classes/java/net/http/WebSocket.java line 151:
> 
>> 149:          * moment a connection is requested until it is established. The elapsed
>> 150:          * time includes any SSL/TLS handshake.
>> 151:          *
> 
> This change should probably be  ammended. 
> The connectionTimeout for websocket is set as the request timeout for the HTTP upgrade request to websocket.
> So it includes both the handshake and the 101 response.
> Now I wonder if we are missing something that will cancel the timer when handing the connection off to WebSocket. It would be good to double check. We had no failing tests so maybe this is properly handled.

And now I wonder too when the timer gets cancelled for an HTTP/2 upgrade.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2491604215

From vyazici at openjdk.org  Tue Nov  4 18:21:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 18:21:27 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v4]
In-Reply-To: <eeJdtLMXD4ek0ex3wC19FXuT1AZsoV-GtqJvAnz57UQ=.d0e1ccc1-a305-41cf-bc32-3af396ec5ea7@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
 <eeJdtLMXD4ek0ex3wC19FXuT1AZsoV-GtqJvAnz57UQ=.d0e1ccc1-a305-41cf-bc32-3af396ec5ea7@github.com>
Message-ID: <0PjL2ziQeIrOvlinGDl8TpDQLzvESWAqZM3LsIz6W4A=.3c528447-b82b-496f-ad46-663f12b7c193@github.com>

On Tue, 4 Nov 2025 15:16:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
>> 
>> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Apply suggestion from @vy
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Apply suggestion from @vy
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update the test to match the new property name

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27827#pullrequestreview-3418072752

From vyazici at openjdk.org  Tue Nov  4 18:26:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 18:26:34 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v7]
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <4jUf69B2EbyUZV-kYQCODDcEtQ4el1lc25wO3B4XS5E=.97f45db3-d7c7-4f3c-8cef-a2c5f0f30076@github.com>

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Clarify Javadoc on extremums

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27973/files
  - new: https://git.openjdk.org/jdk/pull/27973/files/2634e743..167d3b97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=05-06

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973

PR: https://git.openjdk.org/jdk/pull/27973

From vyazici at openjdk.org  Tue Nov  4 18:26:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 18:26:37 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v6]
In-Reply-To: <xfn_Qnz8OM1P9zVS0XW_peVfS0-ASWoQ6Qdg5iSrBd8=.715c9e74-adfa-4ea2-9ae0-96d9c348229e@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <kPSGt-R9bJg5VwOZhg9LRuRW0Cb2MrslUhHPvWG3i_A=.6a2fe97e-a245-41a1-87fe-6e70f8a085c4@github.com>
 <xfn_Qnz8OM1P9zVS0XW_peVfS0-ASWoQ6Qdg5iSrBd8=.715c9e74-adfa-4ea2-9ae0-96d9c348229e@github.com>
Message-ID: <lACpYC9V71qMg0-7gZu2ws2Do8KD2YD1IPT2TipDlSQ=.04914283-0d52-45e2-be2a-d4e99f4bf936@github.com>

On Tue, 4 Nov 2025 15:28:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use `<p id="overflow">` in Javadoc as suggested in reviews
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 39:
> 
>> 37:  * This class is immutable and thread-safe.
>> 38:  * <p id="overflow">
>> 39:  * Operations that add durations to a {@code Deadline}, whether represented as a
> 
> Suggestion:
> 
>  * Operations that add or subtract durations to a {@code Deadline}, whether represented as a

Applied in 167d3b973c2.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 43:
> 
>> 41:  * nanoseconds) do not throw on numeric overflow if the resulting
>> 42:  * {@code Deadline} would exceed {@link #MAX} or be less than {@link #MIN}.
>> 43:  * Instead, {@code MAX} or {@code MIN} is returned, respectively.
> 
> Suggestion:
> 
>  * Instead, {@code MAX} or {@code MIN} is returned, respectively.
>  * Similarly, methods that return a duration as a {@code long} will either return 
>  * {@link Long#MAX_VALUE} or {@link Long#MIN_VALUE} if the returned quantity would 
>  * exceed the capacity of a {@code long}.

Applied in 167d3b973c2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2491642861
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2491643264

From dfuchs at openjdk.org  Tue Nov  4 18:43:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 4 Nov 2025 18:43:49 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v7]
In-Reply-To: <4jUf69B2EbyUZV-kYQCODDcEtQ4el1lc25wO3B4XS5E=.97f45db3-d7c7-4f3c-8cef-a2c5f0f30076@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <4jUf69B2EbyUZV-kYQCODDcEtQ4el1lc25wO3B4XS5E=.97f45db3-d7c7-4f3c-8cef-a2c5f0f30076@github.com>
Message-ID: <9TrMi4K1sue2VjsFBHljpjSUOjGJN8eGZKnIg3Kxxpk=.97d6a28e-25ad-4377-820d-2e4fe8bdeed6@github.com>

On Tue, 4 Nov 2025 18:26:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify Javadoc on extremums

test/jdk/java/net/httpclient/DurationOverflowTest.java line 88:

> 86:  * @run junit/othervm
> 87:  *      -Djdk.httpclient.keepalive.timeout.h2=9223372036854775807
> 88:  *      -DallowedInfras=h2,h2s

you could probably add h3 since h3 takes its default value from h2.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2491689022

From alanb at openjdk.org  Tue Nov  4 19:57:17 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Nov 2025 19:57:17 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>
Message-ID: <2cuzTthIX1oIW7Zv9oG4IvBSY1c_OV1k5HjP9JeynJg=.f3463afe-49d9-40b2-9081-47c8b65048a6@github.com>

On Tue, 4 Nov 2025 17:32:48 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
>> 
>> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve Javadoc

src/java.base/share/classes/java/net/SocketImpl.java line 362:

> 360:      *
> 361:      * @deprecated This function has always been a no-op.
> 362:      * It is deprecated for removal without any replacement.

The method  description already has "By default, this method does nothing, unless it is overridden in a sub-class".  What would you think about have the deprecated message be reduced down to "This method was intended to allow for protocols that are now obsolete"?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2491879876

From vyazici at openjdk.org  Tue Nov  4 20:04:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 20:04:27 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Shorten `@deprecated` message

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28129/files
  - new: https://git.openjdk.org/jdk/pull/28129/files/41c918cf..c9384b09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28129&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28129&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28129/head:pull/28129

PR: https://git.openjdk.org/jdk/pull/28129

From vyazici at openjdk.org  Tue Nov  4 20:04:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 20:04:29 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v2]
In-Reply-To: <2cuzTthIX1oIW7Zv9oG4IvBSY1c_OV1k5HjP9JeynJg=.f3463afe-49d9-40b2-9081-47c8b65048a6@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <iWd2B5ipaFsiIoP0HodsxVrqxukt2Lt1XaSvQO0FRkQ=.c7553e3d-6388-4586-8696-82ec341580a6@github.com>
 <2cuzTthIX1oIW7Zv9oG4IvBSY1c_OV1k5HjP9JeynJg=.f3463afe-49d9-40b2-9081-47c8b65048a6@github.com>
Message-ID: <h3t4tm2ncDSyb0SShmi7pBoDRbXhSikJgNOMkaKAkBA=.142de2fc-79c1-466b-9a9c-c1f359c9d5fa@github.com>

On Tue, 4 Nov 2025 19:54:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve Javadoc
>
> src/java.base/share/classes/java/net/SocketImpl.java line 362:
> 
>> 360:      *
>> 361:      * @deprecated This function has always been a no-op.
>> 362:      * It is deprecated for removal without any replacement.
> 
> The method  description already has "By default, this method does nothing, unless it is overridden in a sub-class".  What would you think about have the deprecated message be reduced down to "This method was intended to allow for protocols that are now obsolete"?

Implemented in c9384b09ba9. I'm right away updating the CSR specification too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28129#discussion_r2491895289

From vyazici at openjdk.org  Tue Nov  4 20:09:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 20:09:44 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v8]
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <pgeu2LiPirzCjAq-ocJ500BVyEKmqDfxuTyC2-fgHLs=.cdb61536-e75c-4af2-acb7-1be04cf755f9@github.com>

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Test `h3` infra with `j.h.k.timeout.h2`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27973/files
  - new: https://git.openjdk.org/jdk/pull/27973/files/167d3b97..a1163b58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=06-07

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27973/head:pull/27973

PR: https://git.openjdk.org/jdk/pull/27973

From vyazici at openjdk.org  Tue Nov  4 20:09:47 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 4 Nov 2025 20:09:47 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v7]
In-Reply-To: <9TrMi4K1sue2VjsFBHljpjSUOjGJN8eGZKnIg3Kxxpk=.97d6a28e-25ad-4377-820d-2e4fe8bdeed6@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <4jUf69B2EbyUZV-kYQCODDcEtQ4el1lc25wO3B4XS5E=.97f45db3-d7c7-4f3c-8cef-a2c5f0f30076@github.com>
 <9TrMi4K1sue2VjsFBHljpjSUOjGJN8eGZKnIg3Kxxpk=.97d6a28e-25ad-4377-820d-2e4fe8bdeed6@github.com>
Message-ID: <mR1BoSKQmEzw7sEtlPnFWyixpwuNv1tYS4tgwT5AjnA=.5513b123-8d10-462c-a926-f355bb79e3dd@github.com>

On Tue, 4 Nov 2025 18:40:46 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify Javadoc on extremums
>
> test/jdk/java/net/httpclient/DurationOverflowTest.java line 88:
> 
>> 86:  * @run junit/othervm
>> 87:  *      -Djdk.httpclient.keepalive.timeout.h2=9223372036854775807
>> 88:  *      -DallowedInfras=h2,h2s
> 
> you could probably add h3 since h3 takes its default value from h2.

Implemented in a1163b58b88.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2491904855

From michaelm at openjdk.org  Tue Nov  4 21:22:18 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 4 Nov 2025 21:22:18 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v2]
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <P2a-gb1QO9p2gaFhrQ9UEOaEbMwdDFnu9jjkGUvNeEI=.969a21be-452a-4159-ab77-3ed586473e94@github.com>

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  doc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28132/files
  - new: https://git.openjdk.org/jdk/pull/28132/files/8fe3a2bd..5f9f259d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=00-01

  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From michaelm at openjdk.org  Wed Nov  5 08:24:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 08:24:01 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability
In-Reply-To: <rXLiodK-KbAwORZ5oyjYDZlKOwJANSQ6-rX69ebzPdE=.11aa8df0-a38c-4e47-8fea-a15de3fb7fa3@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <rXLiodK-KbAwORZ5oyjYDZlKOwJANSQ6-rX69ebzPdE=.11aa8df0-a38c-4e47-8fea-a15de3fb7fa3@github.com>
Message-ID: <XZX-5RDONHL3MxagP5OmHh1g_VTUgiw99DVP_JhP9x0=.1ed5b380-0098-433f-8a6d-7c7b2d90c23c@github.com>

On Tue, 4 Nov 2025 16:02:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This is a good idea, but it kind of hides the fact that passing 0 may not do what you think it does.
> 
> Typically the pitfall is to assume that if you have an array of bytes then you can can call `sendResponseHeaders` with the array length. The API doc of `sendResponseHeaders` should probably make it clear that 0 is a special value, and that `RSPBODY_CHUNKED` is 0.
> 
> In addition I would suggest adding code snipets showing both cases (one using a byte array and passing `bytes.length == 0 ? RSPBODY_EMPTY : bytes.length` and the other using `RSPBODY_CHUNKED` with e.g. transferring the content of an `InputStream`.

I've added an API note. I'd prefer not to drown the whole spec out with code samples just for this issue if possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3489892074

From michaelm at openjdk.org  Wed Nov  5 08:57:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 08:57:12 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v3]
In-Reply-To: <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>
Message-ID: <MaSbpxZ310HScdYhlMVXVZPHLuBx7AuTiPqUo8tb3Uw=.a480fe34-e41a-4eb5-9707-5089d913925e@github.com>

On Tue, 4 Nov 2025 11:11:26 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> Fixes JDK-8371009.
>> 
>> The synchronous HttpClient example references `request` without defining it.
>> This patch adds a minimal HttpRequest initialization immediately before the
>> synchronous example (mirroring the asynchronous snippet) so the example
>> compiles and runs as-is.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8371009: fix indent

Marked as reviewed by michaelm (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28084#pullrequestreview-3420638042

From michaelm at openjdk.org  Wed Nov  5 08:57:15 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 08:57:15 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v2]
In-Reply-To: <h3mgsmQ3jilplz911FtQhhQxeOOgQgb-BKphs6SIolk=.50d1bf66-8d3b-4323-bf9a-d568dc5cb971@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <BTLPkaNof7Zm87wnss_ebiBA9tV0WZuGPL8tAwCYMaQ=.bcac1f3e-570d-4754-a2bc-3eaab9f1b298@github.com>
 <h3mgsmQ3jilplz911FtQhhQxeOOgQgb-BKphs6SIolk=.50d1bf66-8d3b-4323-bf9a-d568dc5cb971@github.com>
Message-ID: <Ublc7MqsOv6QXvTKkP-RRVurFslCBdzjnjqcPPZ1-r4=.f86188d4-3d41-4e73-ba8d-360a12ba1cf4@github.com>

On Sat, 1 Nov 2025 15:50:33 GMT, EunHyunsu <duke at openjdk.org> wrote:

> @Michael-Mc-Mahon I believe this change doesn't require a CSR since it's just fixing an example.
> 
> @ehs208 did you generate `make docs-jdk-api` and verify that the generated API documentation correctly displays the new changes?

I agree this is not a spec or behavior change, so should not require a CSR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3489997460

From vyazici at openjdk.org  Wed Nov  5 10:29:22 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 5 Nov 2025 10:29:22 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v9]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <yqmUrrZv2aHchzgUeYNhIIZiTFISTAG9US73yUcylBs=.37a8546a-8556-4fd3-b210-9caa9a8a5c60@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Cancel timer on 204

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/55396846..480349b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=07-08

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From dfuchs at openjdk.org  Wed Nov  5 10:34:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 10:34:07 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v2]
In-Reply-To: <JM4m7lZFzMR4f14fwZHH2yxQ20GQY6TvPsRIHLAU9q4=.d8b178f1-cc4d-403b-9992-45940d86ccc4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <JM4m7lZFzMR4f14fwZHH2yxQ20GQY6TvPsRIHLAU9q4=.d8b178f1-cc4d-403b-9992-45940d86ccc4@github.com>
Message-ID: <Wrz3Rkk7WTuUm1DYtIXyQW7lTynAPLd2OyESjCU6Sdg=.4ad9fe4f-904a-42c6-8653-0165787b753e@github.com>

On Tue, 4 Nov 2025 17:37:24 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix missing newline at end of EmptyAuthorityTest.java
>   
>   Add missing newline at the end of the file.

src/java.base/share/classes/java/net/HostPortrange.java line 71:

> 69:         if (host.charAt(0) == ':') {
> 70:             throw new IllegalArgumentException("missing host in authority: " + host);
> 71:         }

Throwing if the host part is not present is a different fix - and a change of behavior.
It seems it has always been possible to construct an URLPermission of the form:

`new URLPermission("http://:999/foo");`

I am not sure what that would be useful for - but I'd suggest we track that with another issue if you want to pursue it.

I'd suggest to revert lines 68-71

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27896#discussion_r2493875961

From vyazici at openjdk.org  Wed Nov  5 10:40:41 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 5 Nov 2025 10:40:41 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v9]
In-Reply-To: <yqmUrrZv2aHchzgUeYNhIIZiTFISTAG9US73yUcylBs=.37a8546a-8556-4fd3-b210-9caa9a8a5c60@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <yqmUrrZv2aHchzgUeYNhIIZiTFISTAG9US73yUcylBs=.37a8546a-8556-4fd3-b210-9caa9a8a5c60@github.com>
Message-ID: <kVT5r4goZk2Pm-d2RTW_5ycCEbl452O6PZPQyZZLOnY=.b796b481-3597-4b2e-920b-74a0c6cc2660@github.com>

On Wed, 5 Nov 2025 10:29:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cancel timer on 204

src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 391:

> 389:             // Ensure that the connection is closed or returned to the pool
> 390:             exch.nullBody(response, throwable);
> 391:         });

@dfuch, I've introduced this improvement against 204s, which you internally tipped me, in 480349b672e. Though I could not come up with a way to decently test this. Any suggestions?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2493900320

From dfuchs at openjdk.org  Wed Nov  5 11:39:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 11:39:05 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v8]
In-Reply-To: <pgeu2LiPirzCjAq-ocJ500BVyEKmqDfxuTyC2-fgHLs=.cdb61536-e75c-4af2-acb7-1be04cf755f9@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <pgeu2LiPirzCjAq-ocJ500BVyEKmqDfxuTyC2-fgHLs=.cdb61536-e75c-4af2-acb7-1be04cf755f9@github.com>
Message-ID: <CAt9z6HhK9lp05u4wO8n7sB7Nqf34Nb8iTAjb2N0NWw=.9c2181bf-4a18-426a-b3c0-62d6ba437d76@github.com>

On Tue, 4 Nov 2025 20:09:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test `h3` infra with `j.h.k.timeout.h2`

Marked as reviewed by dfuchs (Reviewer).

test/jdk/java/net/httpclient/whitebox/DeadlineOverflowTestDriver.java line 30:

> 28:  * @modules java.net.http/jdk.internal.net.http.common:+open
> 29:  * @run junit java.net.http/jdk.internal.net.http.common.DeadlineOverflowTest
> 30:  */

Putting the test in the `jdk.internal.net.http.common` package and having a driver to run it was probably unecessary in this case. I think a simple test under `test/jdk/java/net/httpclient` would have worked too since you're only accessing public (even though not exported) APIs.
That said having this test under `.../whitebox/` makes kind of sense too so I'm good with that.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27973#pullrequestreview-3421427378
PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2494089212

From dfuchs at openjdk.org  Wed Nov  5 11:48:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 11:48:16 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
Message-ID: <lsic7TKt-evAQAJ3VL6ZrlvYC-l73hRtasnC9VSEGA0=.7b82fc21-9055-4995-a6dc-a7a712b1ec72@github.com>

On Tue, 4 Nov 2025 20:04:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
>> 
>> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten `@deprecated` message

Looks good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28129#pullrequestreview-3421476561

From alanb at openjdk.org  Wed Nov  5 11:54:05 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Nov 2025 11:54:05 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
Message-ID: <3MKlB8kYKmJ7ZLwmhrIRYdVV7URoXFjr_EOdAByB-FU=.c1e05ed0-10f6-4ccd-af55-418ea417114d@github.com>

On Tue, 4 Nov 2025 20:04:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
>> 
>> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shorten `@deprecated` message

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28129#pullrequestreview-3421501498

From michaelm at openjdk.org  Wed Nov  5 11:58:48 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 11:58:48 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <KqNuXelOjfovXBn3DLlRtFZ_BMulIsjiLh5Er3sUUDs=.f34f0d35-f977-40fd-8281-7775cac1926e@github.com>

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  revert unintended spec change to sendResponseHeaders

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28132/files
  - new: https://git.openjdk.org/jdk/pull/28132/files/5f9f259d..f567e10f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From dfuchs at openjdk.org  Wed Nov  5 12:16:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 12:16:16 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v9]
In-Reply-To: <kVT5r4goZk2Pm-d2RTW_5ycCEbl452O6PZPQyZZLOnY=.b796b481-3597-4b2e-920b-74a0c6cc2660@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <yqmUrrZv2aHchzgUeYNhIIZiTFISTAG9US73yUcylBs=.37a8546a-8556-4fd3-b210-9caa9a8a5c60@github.com>
 <kVT5r4goZk2Pm-d2RTW_5ycCEbl452O6PZPQyZZLOnY=.b796b481-3597-4b2e-920b-74a0c6cc2660@github.com>
Message-ID: <ZhizFgLoWOY3z7Yto4oyDLI30QdtgYnaGizb1f84vu4=.e236698b-da98-4980-a9e4-a758cecf0582@github.com>

On Wed, 5 Nov 2025 10:37:53 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cancel timer on 204
>
> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 391:
> 
>> 389:             // Ensure that the connection is closed or returned to the pool
>> 390:             exch.nullBody(response, throwable);
>> 391:         });
> 
> @dfuch, I've introduced this improvement against 204s, which you internally tipped me, in 480349b672e. Though I could not come up with a way to decently test this. Any suggestions?

That's probably not testable. In case of nullBody() the CF will be immediately completed anyway - so the only thing you'd risk at this point is completing exceptionally a CF that was already completed with no observable result.
Cancelling the timer there is "just" bookeeping - making sure we don't keep timers in the queue when they're no longer needed (which is important too - but there'd be no obvious way to test that, short of exposing the timer queue to the test). A whitebox might be able to do that but you'd probably have to add some additional accessors in the product code for testing purposes.

FWIW see https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/httpclient/access/java.net.http/jdk/internal/net/http/Http3ConnectionAccess.java
and the place where it's used:
https://github.com/openjdk/jdk/blob/3e3822ad7eadbb3d86a3b94a6bd858f8c8ef9364/test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java#L120

You might be able to add a couple package-level accessors methods to `HttpClientImpl` to get at the information you need and add your own accessor class (similar to Http3ConnectionAccess.java) in the access library, and then use that within your test. If you do so please add a // comment to explain that the new methods are used by tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2494207904

From duke at openjdk.org  Wed Nov  5 12:23:33 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Nov 2025 12:23:33 GMT
Subject: RFR: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration [v3]
In-Reply-To: <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
 <Z28bwIPEa2dcrqUIcUqbFn6nOGS11b5w4gVASRgvnTE=.b6fd5054-7a9a-47a0-b235-501fa21f0dec@github.com>
Message-ID: <ZP0ubzYvwcX6pZgUhLJp5UjpRcE_keHkVKRDq_43po0=.ab74e2ad-5137-41fb-af0e-346b3c74b9dc@github.com>

On Tue, 4 Nov 2025 11:11:26 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> Fixes JDK-8371009.
>> 
>> The synchronous HttpClient example references `request` without defining it.
>> This patch adds a minimal HttpRequest initialization immediately before the
>> synchronous example (mirroring the asynchronous snippet) so the example
>> compiles and runs as-is.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8371009: fix indent

@ehs208 
Your change (at version 34f8d04b43fe4d8d423ad25218841802d182abee) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3490914559

From dfuchs at openjdk.org  Wed Nov  5 12:29:20 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 12:29:20 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <KqNuXelOjfovXBn3DLlRtFZ_BMulIsjiLh5Er3sUUDs=.f34f0d35-f977-40fd-8281-7775cac1926e@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <KqNuXelOjfovXBn3DLlRtFZ_BMulIsjiLh5Er3sUUDs=.f34f0d35-f977-40fd-8281-7775cac1926e@github.com>
Message-ID: <LJkgmsCtr9fc6a1qFw2kzPlkmNWjm6RLUqB8HHcIRDU=.1aab72af-a654-49f0-860d-f86163bb8613@github.com>

On Wed, 5 Nov 2025 11:58:48 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert unintended spec change to sendResponseHeaders

Thanks for adding the `@apiNote` and explicitely mentionning the value of `RSPBODY_CHUNKED`. The new text looks good to me now.

Could be good to double check what would happen if you have something like that:


public void handle(final HttpExchange exchange) throws IOException {
     byte[] bytes = getResponseBody(exchange.getRequestURI());
     long fixedlen = bytes.length == 0 ? RSPBODY_EMPTY : bytes.length;
     exchange.sendResponseHeaders(200, fixedlen);
     try (OutputStream os = exchange.getResponseBody()) {
         os.write(bytes);
     }
}

where `getResponseBody(exchange.getRequestURI());` returns `new byte[0];`
will os.write throw, or will it be no-op?
If it throws then should it be specified that `sendResponseHeaders` closes the output stream?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28132#pullrequestreview-3421685185

From vyazici at openjdk.org  Wed Nov  5 13:16:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 5 Nov 2025 13:16:12 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v8]
In-Reply-To: <CAt9z6HhK9lp05u4wO8n7sB7Nqf34Nb8iTAjb2N0NWw=.9c2181bf-4a18-426a-b3c0-62d6ba437d76@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <pgeu2LiPirzCjAq-ocJ500BVyEKmqDfxuTyC2-fgHLs=.cdb61536-e75c-4af2-acb7-1be04cf755f9@github.com>
 <CAt9z6HhK9lp05u4wO8n7sB7Nqf34Nb8iTAjb2N0NWw=.9c2181bf-4a18-426a-b3c0-62d6ba437d76@github.com>
Message-ID: <iOPAqQfEBKSa0eGOLQnkxu5AzxUVgBOyZa4SykN-DXQ=.c778602c-feb3-4dea-814d-dc34516ac324@github.com>

On Wed, 5 Nov 2025 11:35:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test `h3` infra with `j.h.k.timeout.h2`
>
> test/jdk/java/net/httpclient/whitebox/DeadlineOverflowTestDriver.java line 30:
> 
>> 28:  * @modules java.net.http/jdk.internal.net.http.common:+open
>> 29:  * @run junit java.net.http/jdk.internal.net.http.common.DeadlineOverflowTest
>> 30:  */
> 
> Putting the test in the `jdk.internal.net.http.common` package and having a driver to run it was probably unecessary in this case. I think a simple test under `test/jdk/java/net/httpclient` would have worked too since you're only accessing public (even though not exported) APIs.
> That said having this test under `.../whitebox/` makes kind of sense too so I'm good with that.

Since `Deadline::of` is package-private, I've placed the test to `whitebox` with a `package jdk.internal.net.http.common` preamble.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2494428645

From michaelm at openjdk.org  Wed Nov  5 13:45:37 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 13:45:37 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <CWhe4stwgitPqg4rP-7M3UXGugWhObwxeq1HrK-Luak=.a3834146-d673-4225-9bf9-8a6a0efb6fab@github.com>

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  clarify empty byte[] behavior

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28132/files
  - new: https://git.openjdk.org/jdk/pull/28132/files/f567e10f..df70fb52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From michaelm at openjdk.org  Wed Nov  5 13:45:38 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 13:45:38 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v3]
In-Reply-To: <LJkgmsCtr9fc6a1qFw2kzPlkmNWjm6RLUqB8HHcIRDU=.1aab72af-a654-49f0-860d-f86163bb8613@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <KqNuXelOjfovXBn3DLlRtFZ_BMulIsjiLh5Er3sUUDs=.f34f0d35-f977-40fd-8281-7775cac1926e@github.com>
 <LJkgmsCtr9fc6a1qFw2kzPlkmNWjm6RLUqB8HHcIRDU=.1aab72af-a654-49f0-860d-f86163bb8613@github.com>
Message-ID: <OoXM-7EJRqI0gmuKavOKvCJd6GcdkWVajCEQxT2jwQg=.71f73dc9-1464-469e-ba16-6db3ce0cac07@github.com>

On Wed, 5 Nov 2025 12:26:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for adding the `@apiNote` and explicitely mentionning the value of `RSPBODY_CHUNKED`. The new text looks good to me now.
> 
> Could be good to double check what would happen if you have something like that:
> 
> ```
> public void handle(final HttpExchange exchange) throws IOException {
>      byte[] bytes = getResponseBody(exchange.getRequestURI());
>      long fixedlen = bytes.length == 0 ? RSPBODY_EMPTY : bytes.length;
>      exchange.sendResponseHeaders(200, fixedlen);
>      try (OutputStream os = exchange.getResponseBody()) {
>          os.write(bytes);
>      }
> }
> ```
> 
> where `getResponseBody(exchange.getRequestURI());` returns `new byte[0];` will os.write throw, or will it be no-op? If it throws then should it be specified that `sendResponseHeaders` closes the output stream?

That would work fine. What possibly needs to be mentioned is that with chunked encoding, you must always
close the output stream explicitly (or through a try with resources block as in your example). I will add
a sentence to that effect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3491274498

From dfuchs at openjdk.org  Wed Nov  5 14:21:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 14:21:23 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values [v8]
In-Reply-To: <iOPAqQfEBKSa0eGOLQnkxu5AzxUVgBOyZa4SykN-DXQ=.c778602c-feb3-4dea-814d-dc34516ac324@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <pgeu2LiPirzCjAq-ocJ500BVyEKmqDfxuTyC2-fgHLs=.cdb61536-e75c-4af2-acb7-1be04cf755f9@github.com>
 <CAt9z6HhK9lp05u4wO8n7sB7Nqf34Nb8iTAjb2N0NWw=.9c2181bf-4a18-426a-b3c0-62d6ba437d76@github.com>
 <iOPAqQfEBKSa0eGOLQnkxu5AzxUVgBOyZa4SykN-DXQ=.c778602c-feb3-4dea-814d-dc34516ac324@github.com>
Message-ID: <dFkotz1wqP7cS9UzJYXghNLfo8AHsD3tZqxRNuv6_W4=.2b7bf4e0-cf80-4758-a84f-f0a14af54574@github.com>

On Wed, 5 Nov 2025 13:13:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/whitebox/DeadlineOverflowTestDriver.java line 30:
>> 
>>> 28:  * @modules java.net.http/jdk.internal.net.http.common:+open
>>> 29:  * @run junit java.net.http/jdk.internal.net.http.common.DeadlineOverflowTest
>>> 30:  */
>> 
>> Putting the test in the `jdk.internal.net.http.common` package and having a driver to run it was probably unecessary in this case. I think a simple test under `test/jdk/java/net/httpclient` would have worked too since you're only accessing public (even though not exported) APIs.
>> That said having this test under `.../whitebox/` makes kind of sense too so I'm good with that.
>
> Since `Deadline::of` is package-private, I've placed the test to `whitebox` with a `package jdk.internal.net.http.common` preamble.

Oh - OK. Makes sense then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2494715793

From dfuchs at openjdk.org  Wed Nov  5 14:23:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 14:23:44 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <CWhe4stwgitPqg4rP-7M3UXGugWhObwxeq1HrK-Luak=.a3834146-d673-4225-9bf9-8a6a0efb6fab@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <CWhe4stwgitPqg4rP-7M3UXGugWhObwxeq1HrK-Luak=.a3834146-d673-4225-9bf9-8a6a0efb6fab@github.com>
Message-ID: <pMJJz09xdvXl9Y63n1xx8q2RFNPH43FC-_a5PW4HCeM=.294b90a1-dcd8-4eff-b70b-60d43ea54d78@github.com>

On Wed, 5 Nov 2025 13:45:37 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify empty byte[] behavior

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28132#pullrequestreview-3422363527

From duke at openjdk.org  Wed Nov  5 14:30:52 2025
From: duke at openjdk.org (Mahied Maruf)
Date: Wed, 5 Nov 2025 14:30:52 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
In-Reply-To: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com>
References: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com>
Message-ID: <HwfX3GDh6eEdg9bwx11I8db5L7Z2-88r_TARBJXVo_M=.08cdf1e1-d6f4-48f6-9df5-11583951643e@github.com>

On Sat, 25 Oct 2025 16:02:05 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Remaking the PR since I messed up the upstream merge on the other one.
> 
> - adds a flag to ExchangeImpl to signal whether the current request is a GET Upgrade request
> - Adds a new `UpgradeInputStream`/`UpgradeOutputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UpgradeInputStream`

LGTM ? I need this patch for websocket support.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27989#pullrequestreview-3422385900

From dfuchs at openjdk.org  Wed Nov  5 14:56:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 14:56:18 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <CWhe4stwgitPqg4rP-7M3UXGugWhObwxeq1HrK-Luak=.a3834146-d673-4225-9bf9-8a6a0efb6fab@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <CWhe4stwgitPqg4rP-7M3UXGugWhObwxeq1HrK-Luak=.a3834146-d673-4225-9bf9-8a6a0efb6fab@github.com>
Message-ID: <Vky_GDREmn0O9FtMo1NZtfJKrJzff_SPUJIrvQzV0uI=.8c53dd27-cc2d-46ed-a860-287637f9893e@github.com>

On Wed, 5 Nov 2025 13:45:37 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify empty byte[] behavior

src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 91:

> 89:      * @since 26
> 90:      */
> 91:     public static final long RSPBODY_CHUNKED = 0;

Should we add:

@see #sendResponseHeaders(int, long)


to make it clearer what these constants are for?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2494903318

From duke at openjdk.org  Wed Nov  5 15:00:50 2025
From: duke at openjdk.org (EunHyunsu)
Date: Wed, 5 Nov 2025 15:00:50 GMT
Subject: Integrated: 8371009: HttpClient javadoc synchronous example missing
 HttpRequest variable declaration
In-Reply-To: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com>
Message-ID: <MqcO7WP2pYvA8u0pWXCNkUaF8dgxpgRVTprvxngi8bI=.9a0ff0be-34ec-4a4c-9900-a9565d97c50d@github.com>

On Fri, 31 Oct 2025 10:22:06 GMT, EunHyunsu <duke at openjdk.org> wrote:

> Fixes JDK-8371009.
> 
> The synchronous HttpClient example references `request` without defining it.
> This patch adds a minimal HttpRequest initialization immediately before the
> synchronous example (mirroring the asynchronous snippet) so the example
> compiles and runs as-is.

This pull request has now been integrated.

Changeset: 973dc3fc
Author:    EunHyunsu <ehs208 at naver.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/973dc3fc47b249bb392d277880dcac0940f62771
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration

Reviewed-by: dfuchs, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/28084

From michaelm at openjdk.org  Wed Nov  5 15:09:48 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 15:09:48 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v4]
In-Reply-To: <Vky_GDREmn0O9FtMo1NZtfJKrJzff_SPUJIrvQzV0uI=.8c53dd27-cc2d-46ed-a860-287637f9893e@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <CWhe4stwgitPqg4rP-7M3UXGugWhObwxeq1HrK-Luak=.a3834146-d673-4225-9bf9-8a6a0efb6fab@github.com>
 <Vky_GDREmn0O9FtMo1NZtfJKrJzff_SPUJIrvQzV0uI=.8c53dd27-cc2d-46ed-a860-287637f9893e@github.com>
Message-ID: <hSE_AapmkW_8N9xKsyDxkq5j95j5UkksUfe4N6I7Tj0=.6868e345-9892-4f18-9ee6-155339a4f1a3@github.com>

On Wed, 5 Nov 2025 14:53:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Should we add:
> 
> ```
> @see #sendResponseHeaders(int, long)
> ```
> 
> to make it clearer what these constants are for?

Good idea

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2494969269

From michaelm at openjdk.org  Wed Nov  5 15:17:35 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 5 Nov 2025 15:17:35 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28132/files
  - new: https://git.openjdk.org/jdk/pull/28132/files/df70fb52..5633b0de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=03-04

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From dfuchs at openjdk.org  Wed Nov  5 15:54:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 15:54:16 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
Message-ID: <KGIssz6CiYFGqVd-xc-yA7Krg8LRHVjQ84s-CQtkplM=.03330af8-af02-445c-9898-0faf08ba7e33@github.com>

On Wed, 5 Nov 2025 15:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28132#pullrequestreview-3422975907

From duke at openjdk.org  Wed Nov  5 16:07:45 2025
From: duke at openjdk.org (Ethan McCue)
Date: Wed, 5 Nov 2025 16:07:45 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
Message-ID: <2pasx1tYGTzy2UT8sELBKOplFh9hrljkvgJ6THwRxW0=.6059c2af-c61f-482a-9b51-09a213464d68@github.com>

On Wed, 5 Nov 2025 15:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

I've said all my objections before. I think if we waited for member patterns we could have an API that doesn't need the constants and I think that the constants do not solve for the bad patterns today.

https://github.com/openjdk/jdk/pull/18955

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3492065160

From duke at openjdk.org  Wed Nov  5 16:11:00 2025
From: duke at openjdk.org (Ethan McCue)
Date: Wed, 5 Nov 2025 16:11:00 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
Message-ID: <VWi3pvJV8nyuW3OFU2h-nvTMDGTENMQyHXgwZvcdqlU=.84f3ead5-6ac8-4662-a2cf-0a9009cdae9a@github.com>

On Wed, 5 Nov 2025 15:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

> I think it makes the API very slightly better, but in a way that would detract from future attempts to make the API holistically better to use.

Seriously consider that if we had member patterns would we add this API? If the answer is no (and I think it is no) lets just not do it

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3492076083

From duke at openjdk.org  Wed Nov  5 16:17:00 2025
From: duke at openjdk.org (Ethan McCue)
Date: Wed, 5 Nov 2025 16:17:00 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
Message-ID: <0Dg0UcpoNZP2rgrWqv-ptEeCfr5IvPG_KdYzTQOrMg4=.7bedee3d-aee6-4303-b95d-e2b0bef4b3f5@github.com>

On Wed, 5 Nov 2025 15:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

public void handle(final HttpExchange exchange) throws IOException {
     byte[] bytes = getResponseBody(exchange.getRequestURI());
     long fixedlen = bytes.length == 0 ? RSPBODY_EMPTY : bytes.length;
     exchange.sendResponseHeaders(200, fixedlen);
     try (OutputStream os = exchange.getResponseBody()) {
         os.write(bytes);
     }
}


versus


public void handle(final HttpExchange exchange) throws IOException {
     byte[] bytes = getResponseBody(exchange.getRequestURI());
     exchange.sendResponseHeaders(200, ResponseLength.known(bytes));
     try (OutputStream os = exchange.getResponseBody()) {
         os.write(bytes);
     }
}


This has the benefit of us being able to deprecate `.sendResponseHeaders(int, long)` to guide usage to it. The only reason not to do it today is that we lack the ability to make `ResponseLength` in the way that is ideal (with `known(...)` and `unknown()` having matching extraction patterns)

And in the presence of such an API there are no uses for the constants so...do you see my frustration? You need to know to look for `RSPBODY_EMPTY` and write `bytes.length == 0 ? RSPBODY_EMPTY : bytes.length;` This will not lead to a better result.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3492106632

From dfuchs at openjdk.org  Wed Nov  5 16:34:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 5 Nov 2025 16:34:49 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
Message-ID: <LJhq9KHQwWQmbin-WQkfTUiQnB-WEuc_eYuiOjkw39c=.cea46a69-a0dd-4e3e-84d0-03667f736e2d@github.com>

On Wed, 5 Nov 2025 15:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

I don't disagree but adding new APIs is a bigger maintenance cost than adding two simple constants.
I believe the proposed change will improve the usability. The `sendResponseHeaders(int, long)` cannot be removed, and even if we added a new API it would still be here. There's also the impacts on the SPI to take into account.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3492203779

From vyazici at openjdk.org  Thu Nov  6 06:25:16 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 06:25:16 GMT
Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values
In-Reply-To: <tJ07ZwYxttUz9LS-gieGLATHc3NQ7Kt-vzSm32YbKCg=.7206d5a3-2b7b-4629-a0d3-28c264977163@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
 <x5mOWmtcQgbqeaKgQYV8LCDxTxWf4Ih5Me82HrmiMxE=.08a1404c-ed21-4c10-b0d1-009d23963c51@github.com>
 <tJ07ZwYxttUz9LS-gieGLATHc3NQ7Kt-vzSm32YbKCg=.7206d5a3-2b7b-4629-a0d3-28c264977163@github.com>
Message-ID: <fHmhxZyiQ0UXEDXJQIRkL4Q0bVMXOE6ZGt66p_f555Q=.78c849a1-3b84-428e-ad27-3445ebc41a85@github.com>

On Wed, 29 Oct 2025 09:15:31 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>>> We might soon have saturating addition functionality in `java.time.Instant`; see: #27549
>> 
>> Great tip! ? I will hold this PR until #27549 gets merged, and use `Instant::plusSaturated` in `Deadline::plus*` and `::minus` methods.
>> 
>>> I note that `jdk.internal.net.http.common.Deadline` also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the `minus` method in the codebase can be reimplemented alternatively. In which case `Deadline` could delete `minus`.
>> 
>> I also have my reservations regarding the rich, yet seldom used API surface of `Deadline`. But revamping it is out of the scope of this work.
>> 
>>> Furthermore, if there's no need for saturating subtraction, do we need the `Deadline` class? What does it provide, that `Instant` does not?
>> 
>> In short, `Instant` is not necessarily generated using a monotonically-increasing `InstantSource`. `Deadline` is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See [this conversation for details](https://github.com/openjdk/jdk/pull/14450#pullrequestreview-1479500686).
>
> @vy, `Instant.plusSaturating` is in the mainline: https://github.com/openjdk/jdk/commit/2758c6fda2f774d98ef0c24535a7f7e9fc722379

@pavelrappo, @dfuch, thanks so much for your kind assistance. ?
Tier 1-2 is clear.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27973#issuecomment-3495270664

From vyazici at openjdk.org  Thu Nov  6 06:25:18 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 06:25:18 GMT
Subject: Integrated: 8368528: HttpClient.Builder.connectTimeout should accept
 arbitrarily large values
In-Reply-To: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
References: <mCs3L3fOAslVQyVpOxtMOqLgRSW_bDs6nU_DUe_-XDc=.72cd5f1a-dc16-49ae-ba97-3efeb8bdbeca@github.com>
Message-ID: <omArF3It7fTKgHtT1qyuiujxYyz6YLXa21wxhVQ1dWs=.495af5ef-372a-454f-8d80-048cd1529f24@github.com>

On Fri, 24 Oct 2025 12:10:38 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs.

This pull request has now been integrated.

Changeset: c754e3e0
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c754e3e095cd367de9d3f69a4afb0c4be53a9342
Stats:     655 lines in 5 files changed: 598 ins; 34 del; 23 mod

8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/27973

From duke at openjdk.org  Thu Nov  6 10:34:45 2025
From: duke at openjdk.org (Peyang)
Date: Thu, 6 Nov 2025 10:34:45 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v12]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <BkKKQhFzjR0ezI-X5a-Mq5EjO0Hw2J2_qbXFY0QfUoU=.1b2ba3c3-0bc7-4b75-8232-b464781347db@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request incrementally with one additional commit since the last revision:

  Replace IOException with EOFException for unexpected EOF in FileServerHandler

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28021/files
  - new: https://git.openjdk.org/jdk/pull/28021/files/2540945c..060ebc00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=10-11

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From duke at openjdk.org  Thu Nov  6 10:34:46 2025
From: duke at openjdk.org (Peyang)
Date: Thu, 6 Nov 2025 10:34:46 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v3]
In-Reply-To: <MWV1cLmYICqXEleBxVC99dduQ4YkWy5jz8wjdep7bVM=.d3ec4940-6d44-4367-a97a-b1379c8c30c8@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com>
 <Rp5JVeqbd9fusu4EqJz7QtFLVMItbL52fcy0j7AtQDM=.29df8ecb-b8e2-43f3-855d-0ee4ebe52202@github.com>
 <QHlRnGsfKZJzp0S2pCiDNGoyVhzHdvN6Zxf9XucwDUU=.1edd4e3a-cb38-4198-b7c6-033b2b56ec2c@github.com>
 <MWV1cLmYICqXEleBxVC99dduQ4YkWy5jz8wjdep7bVM=.d3ec4940-6d44-4367-a97a-b1379c8c30c8@github.com>
Message-ID: <2C2gnltOpx-qxi02X1AhX-EfisruR6zET_IrAch0Axw=.29835aa9-87fa-4f71-9241-e88a78e71c73@github.com>

On Fri, 31 Oct 2025 11:23:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello @dfuch,
>> 
>> Thank you for the review. I have completed all the requested changes: formatting fixes, additional unit tests, and updates to the JavaDoc of `SimpleFileServer`.
>> 
>> Regarding the CSR, I am not listed in the Census and therefore do not have a JBS/OpenJDK account to proceed with it.
>> Would it be possible for you to either issue an account for me or handle the CSR on your side?
>> If either option works, I can provide the necessary information, including the full text for the CSR ticket.
>> 
>> Thank you very much for your understanding.
>
>> Regarding the CSR, I am not listed in the Census and therefore do not have a JBS/OpenJDK account to proceed with it.
> 
> No problem - one of us will create the CSR, when we have setlled on the documentation and implementation changes and the PR is approved or close to be approved.

Thanks @dfuch, @fandreuz, @Michael-Mc-Mahon and @efge for the detailed reviews.
Since the discussion has become quite long, here?s a summary of the feedback and how it was addressed.

---

#### @dfuch

> ETag is an entirely separate feature from Range and should be in its own separate follow-up Jira ticket and PR.

-> Removed ETag-related code and tests in a separate commit.

> Support for Range header will need to be documented in `SimpleFileServer.java`.

-> Updated the documentation to mention HTTP Range request support.

> I would expect a validation of the ranges list before we serve them. 

->  Implemented range list normalization: overlapping or unsorted ranges are merged and sorted before returning, following [RFC 9110 ?15.3.7.2](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.3.7.2-3).


---

#### @Michael-Mc-Mahon

> We probably should send the `Accept-Ranges` header in response to a HEAD request also.

-> Confirmed that `Accept-Ranges` is already included for HEAD requests.

> Do we need to support `If-Range` with this PR? ? It seems like it belongs more with a general conditional-requests feature.  

-> Removed the initial `If-Range` + ETag handling; this will be covered by a future follow-up.

> Is this not an error situation, if we reach EOF and have only partially returned the requested range?

-> Updated the implementation to throw an `EOFException` and close the connection when EOF is reached before completing the requested range.

---

#### General

> General comments about formatting and tests  

->  Fixed formatting, added more tests, and improved range header parsing and validation (ensuring ranges are sorted and merged if overlapping).

---

### Still open

- CSR creation/approval (maintainer side)  
- Clarify whether `If-Range` will remain partial (Last-Modified based) or gain full ETag support later  
- Final review of the range-merging logic and corresponding tests

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3496435676

From djelinski at openjdk.org  Thu Nov  6 10:43:20 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Nov 2025 10:43:20 GMT
Subject: RFR: 8370024: HttpClient: QUIC congestion controller doesn't implement
 pacing
Message-ID: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>

Implement pacing for QUIC.

This is required by RFC 9002. Also, it improves the network utilization on links with long round-trip times.

The pacing algorithm itself was created based on the suggestions found in RFC 9002, and on the description of the Linux pacing algorithm.

Pacing is enabled when the round-trip time is less than twice the period at which the selector timeout fires. On Linux the selector timeout fires every millisecond, on Windows it's 15.6 milliseconds by default.

HttpClient tests came back clean.

-------------

Commit messages:
 - Fix race in pacer updates, increase low-RTT quota
 - Fix CRLF
 - Keep track of pacer-limited events
 - Less verbose CC logging
 - Implement packet pacing

Changes: https://git.openjdk.org/jdk/pull/28156/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370024
  Stats: 674 lines in 7 files changed: 658 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28156/head:pull/28156

PR: https://git.openjdk.org/jdk/pull/28156

From dfuchs at openjdk.org  Thu Nov  6 11:13:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 11:13:15 GMT
Subject: RFR: 8370024: HttpClient: QUIC congestion controller doesn't
 implement pacing
In-Reply-To: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
References: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
Message-ID: <Mz3DPusSGogtG_T8hqbmzrrpugJMZkn-Yy_CjUC4vno=.8dcc7808-cf68-4e25-a12b-4a0a0870f48b@github.com>

On Wed, 5 Nov 2025 18:04:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Implement pacing for QUIC.
> 
> This is required by RFC 9002. Also, it improves the network utilization on links with long round-trip times.
> 
> The pacing algorithm itself was created based on the suggestions found in RFC 9002, and on the description of the Linux pacing algorithm.
> 
> Pacing is enabled when the round-trip time is less than twice the period at which the selector timeout fires. On Linux the selector timeout fires every millisecond, on Windows it's 15.6 milliseconds by default.
> 
> HttpClient tests came back clean.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicPacer.java line 177:

> 175:         long rttMicros = rttEstimator.state().smoothedRttMicros();
> 176:         long cwnd = congestionController.congestionWindow();
> 177:         return lastUpdate.plus(Duration.ofNanos(rttMicros

you could consider using the two args version of `plus` that can take ChronoUnit.MICROS.

    public Deadline plus(long amountToAdd, TemporalUnit unit) { ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28156#discussion_r2498537252

From vyazici at openjdk.org  Thu Nov  6 12:13:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 12:13:37 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v10]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <DftS9vAGN9eo6OC7uNzjZNFkra4Lp3WDpwuNAHOuTEM=.8894558e-f909-4f1e-880e-94363c5edc40@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Clarify WebSocket behaviour and test it
 - Verify no lingering response timers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/480349b6..c5eae908

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=08-09

  Stats: 207 lines in 7 files changed: 195 ins; 2 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Thu Nov  6 12:13:38 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 12:13:38 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v8]
In-Reply-To: <izz61VkzwQHYZX0RiMsn1FKg0CJFrb9HVrhVBGdVRYc=.7ce26430-0d6f-41d6-8ca7-d85fb152e05b@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DBUCH-HWWPV437hdG9Fpj--4uxXM-552XPcnsdPCrZo=.cf043009-cd8a-47fa-a5f1-7db1461629b8@github.com>
 <5f7komVMjMAg3Dck_trHLmn-gUOJp3nOCFlzkPa9NJM=.76449183-c2e4-4b7a-ae5b-c71c9d954a51@github.com>
 <izz61VkzwQHYZX0RiMsn1FKg0CJFrb9HVrhVBGdVRYc=.7ce26430-0d6f-41d6-8ca7-d85fb152e05b@github.com>
Message-ID: <rgAeZAhbMyMYPHYbJ--FDZz4VBTP0TPRqPF7r6jSDzQ=.4635a118-3d17-4b29-9ba3-09b546df81fa@github.com>

On Tue, 4 Nov 2025 18:08:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/java/net/http/WebSocket.java line 151:
>> 
>>> 149:          * moment a connection is requested until it is established. The elapsed
>>> 150:          * time includes any SSL/TLS handshake.
>>> 151:          *
>> 
>> This change should probably be  ammended. 
>> The connectionTimeout for websocket is set as the request timeout for the HTTP upgrade request to websocket.
>> So it includes both the handshake and the 101 response.
>> Now I wonder if we are missing something that will cancel the timer when handing the connection off to WebSocket. It would be good to double check. We had no failing tests so maybe this is properly handled.
>
> And now I wonder too when the timer gets cancelled for an HTTP/2 upgrade.

In c5eae908f27, clarified the WebSocket documentation and added tests to verify its behaviour.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2498716737

From vyazici at openjdk.org  Thu Nov  6 12:13:39 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 12:13:39 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v9]
In-Reply-To: <ZhizFgLoWOY3z7Yto4oyDLI30QdtgYnaGizb1f84vu4=.e236698b-da98-4980-a9e4-a758cecf0582@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <yqmUrrZv2aHchzgUeYNhIIZiTFISTAG9US73yUcylBs=.37a8546a-8556-4fd3-b210-9caa9a8a5c60@github.com>
 <kVT5r4goZk2Pm-d2RTW_5ycCEbl452O6PZPQyZZLOnY=.b796b481-3597-4b2e-920b-74a0c6cc2660@github.com>
 <ZhizFgLoWOY3z7Yto4oyDLI30QdtgYnaGizb1f84vu4=.e236698b-da98-4980-a9e4-a758cecf0582@github.com>
Message-ID: <k4Z9spYNH7wk4tc2OlznBPhmR62O1JzzqyHntyaq3gE=.04985e52-0a71-4db4-8210-b4d48b8b9d17@github.com>

On Wed, 5 Nov 2025 12:13:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 391:
>> 
>>> 389:             // Ensure that the connection is closed or returned to the pool
>>> 390:             exch.nullBody(response, throwable);
>>> 391:         });
>> 
>> @dfuch, I've introduced this improvement against 204s, which you internally tipped me, in 480349b672e. Though I could not come up with a way to decently test this. Any suggestions?
>
> That's probably not testable. In case of nullBody() the CF will be immediately completed anyway - so the only thing you'd risk at this point is completing exceptionally a CF that was already completed with no observable result.
> Cancelling the timer there is "just" bookeeping - making sure we don't keep timers in the queue when they're no longer needed (which is important too - but there'd be no obvious way to test that, short of exposing the timer queue to the test). A whitebox might be able to do that but you'd probably have to add some additional accessors in the product code for testing purposes.
> 
> FWIW see https://github.com/openjdk/jdk/blob/master/test/jdk/java/net/httpclient/access/java.net.http/jdk/internal/net/http/Http3ConnectionAccess.java
> and the place where it's used:
> https://github.com/openjdk/jdk/blob/3e3822ad7eadbb3d86a3b94a6bd858f8c8ef9364/test/jdk/java/net/httpclient/http3/H3HeaderSizeLimitTest.java#L120
> 
> You might be able to add a couple package-level accessors methods to `HttpClientImpl` to get at the information you need and add your own accessor class (similar to Http3ConnectionAccess.java) in the access library, and then use that within your test. If you do so please add a // comment to explain that the new methods are used by tests.

I'm not very keen on hooking into internals, but I guess there is no other way. Implemented as suggested in 4eac3af5074.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2498717132

From dfuchs at openjdk.org  Thu Nov  6 12:28:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 12:28:07 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v10]
In-Reply-To: <DftS9vAGN9eo6OC7uNzjZNFkra4Lp3WDpwuNAHOuTEM=.8894558e-f909-4f1e-880e-94363c5edc40@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DftS9vAGN9eo6OC7uNzjZNFkra4Lp3WDpwuNAHOuTEM=.8894558e-f909-4f1e-880e-94363c5edc40@github.com>
Message-ID: <fnWh2iF9gm10kcgbAuvuxdSOdzW8BG8iuoUq4J01J58=.2cca6ca3-76f2-4c80-9ef1-7a370ac36ae6@github.com>

On Thu, 6 Nov 2025 12:13:37 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Clarify WebSocket behaviour and test it
>  - Verify no lingering response timers

test/jdk/java/net/httpclient/websocket/WebSocketTest.java line 172:

> 170:                         .newWebSocketBuilder()
> 171:                         .buildAsync(server.getURI(), webSocketListener)
> 172:                         .join();

Shouldn't you add a `connectTimeout` to the web socket builder? Otherwise of course you won't find any :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2498769015

From djelinski at openjdk.org  Thu Nov  6 12:37:21 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Nov 2025 12:37:21 GMT
Subject: RFR: 8370024: HttpClient: QUIC congestion controller doesn't
 implement pacing [v2]
In-Reply-To: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
References: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
Message-ID: <agAYlA1R78gt2PfJ8DyhQTszllwL5h472sgXE0u5XeA=.a080b9d8-57ad-4dcd-b374-d5a106276398@github.com>

> Implement pacing for QUIC.
> 
> This is required by RFC 9002. Also, it improves the network utilization on links with long round-trip times.
> 
> The pacing algorithm itself was created based on the suggestions found in RFC 9002, and on the description of the Linux pacing algorithm.
> 
> Pacing is enabled when the round-trip time is less than twice the period at which the selector timeout fires. On Linux the selector timeout fires every millisecond, on Windows it's 15.6 milliseconds by default.
> 
> HttpClient tests came back clean.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary object allocation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28156/files
  - new: https://git.openjdk.org/jdk/pull/28156/files/dab80e58..2bd6a87c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28156&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28156&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28156/head:pull/28156

PR: https://git.openjdk.org/jdk/pull/28156

From djelinski at openjdk.org  Thu Nov  6 12:37:23 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 6 Nov 2025 12:37:23 GMT
Subject: RFR: 8370024: HttpClient: QUIC congestion controller doesn't
 implement pacing [v2]
In-Reply-To: <Mz3DPusSGogtG_T8hqbmzrrpugJMZkn-Yy_CjUC4vno=.8dcc7808-cf68-4e25-a12b-4a0a0870f48b@github.com>
References: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
 <Mz3DPusSGogtG_T8hqbmzrrpugJMZkn-Yy_CjUC4vno=.8dcc7808-cf68-4e25-a12b-4a0a0870f48b@github.com>
Message-ID: <8Jvl3hYj39Z2dEeIr7uLYxgwqvUXzPmqu_jjhiklnno=.1cdac034-4201-4cb0-b545-28efca7cdea5@github.com>

On Thu, 6 Nov 2025 11:07:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary object allocation
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicPacer.java line 177:
> 
>> 175:         long rttMicros = rttEstimator.state().smoothedRttMicros();
>> 176:         long cwnd = congestionController.congestionWindow();
>> 177:         return lastUpdate.plus(Duration.ofNanos(rttMicros
> 
> you could consider using the two args version of `plus` that can take ChronoUnit.MICROS.
> 
>     public Deadline plus(long amountToAdd, TemporalUnit unit) { ...

Good catch! Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28156#discussion_r2498791230

From vyazici at openjdk.org  Thu Nov  6 13:19:26 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 13:19:26 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v11]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <LRmk6VTU3tyNUpz-c0aE0PMcY5XZxIBqywiI2L2XR-k=.de32039d-a5d7-4304-9e25-c4daf9886097@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:

 - Configure timeout for the `WebSocketTest`
 - Use `var`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/c5eae908..c3210d88

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=09-10

  Stats: 56 lines in 4 files changed: 7 ins; 8 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Thu Nov  6 13:19:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 6 Nov 2025 13:19:29 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v10]
In-Reply-To: <fnWh2iF9gm10kcgbAuvuxdSOdzW8BG8iuoUq4J01J58=.2cca6ca3-76f2-4c80-9ef1-7a370ac36ae6@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DftS9vAGN9eo6OC7uNzjZNFkra4Lp3WDpwuNAHOuTEM=.8894558e-f909-4f1e-880e-94363c5edc40@github.com>
 <fnWh2iF9gm10kcgbAuvuxdSOdzW8BG8iuoUq4J01J58=.2cca6ca3-76f2-4c80-9ef1-7a370ac36ae6@github.com>
Message-ID: <ICyJ_i-UQRqFLfbWC9A0IAEUmV25E5pA-dLDIR1OCJI=.3d233b06-7a05-46b9-aacd-8a035e05c2aa@github.com>

On Thu, 6 Nov 2025 12:25:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Clarify WebSocket behaviour and test it
>>  - Verify no lingering response timers
>
> test/jdk/java/net/httpclient/websocket/WebSocketTest.java line 172:
> 
>> 170:                         .newWebSocketBuilder()
>> 171:                         .buildAsync(server.getURI(), webSocketListener)
>> 172:                         .join();
> 
> Shouldn't you add a `connectTimeout` to the web socket builder? Otherwise of course you won't find any :-)

I was naively expecting `WebSocket.Builder` to inherit `connectTimeout` from the parent `HttpClient`, I was indeed mistaken. Corrected it in c3210d88d0c.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2498931056

From michaelm at openjdk.org  Thu Nov  6 13:28:06 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 6 Nov 2025 13:28:06 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v5]
In-Reply-To: <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <49zq0tabdSRdJikWGen503u41iREKz8YeGZ6EadsGn0=.f6ee24c6-8e26-443b-87d0-c8dc5fbb79e1@github.com>
Message-ID: <FKfEAFrLiYqNWcnKnyX242XIvSRHP6b4DbgRQA1ShV8=.c3aaa3f5-e49b-4e36-8b50-4883ec265240@github.com>

On Wed, 5 Nov 2025 15:17:35 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

I don't agree that you have to go looking for these constants. I think we have to look at it from the point of view of a developer new to the API and someone reading the apidoc for the first time will be clearly drawn to the constant names. I agree a new method with new parameter types would be nicer from an IDE perspective. But if we are going to add a new method then I think we are going to have a wider discussion such as occurred previously with this issue. So, even if we end up doing that and deprecating the present sendResponseHeaders() this effort is not going to get in the way of that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3497258616

From josiahnoel at gmail.com  Thu Nov  6 15:15:44 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Thu, 6 Nov 2025 10:15:44 -0500
Subject: Http3 Client times out for an untrusted certificate
Message-ID: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>

Heya,

I've been testing the Http3 support on windows 11 with build 26-ea+22-2263,
and my request was seemingly just timing out.

After like 3 hours of fiddling, I realized that I forgot to import the
mkcert  rootCA  I was using into the jdk cacerts.

Long story short, when I ran  `keytool -import -trustcacerts -noprompt
-alias mkcert-root-ca   -file "$(mkcert -CAROOT)/rootCA.pem"   -keystore
"$JAVA_HOME/lib/security/cacerts"   -storepass changeit` then it suddenly
began to work.

Perchance is it possible to get a clearer error message?

Feedback wise, I like the new feature, that using it only involves
providing the new enum value is great for me so I don't have to do much to
my internal libraries to make it work.

On an unrelated note, what do we think about adding a HttpServer Create
Convenience Method
<https://mail.openjdk.org/pipermail/net-dev/2025-October/028587.html>?
-- 
Cheers, Josiah.`
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251106/8653cef7/attachment.htm>

From daniel.fuchs at oracle.com  Thu Nov  6 15:37:55 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 6 Nov 2025 15:37:55 +0000
Subject: Http3 Client times out for an untrusted certificate
In-Reply-To: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
Message-ID: <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>

Hi Joshua,

Thanks for reporting this and for trying out HTTP/3!

I have logged https://bugs.openjdk.org/browse/JDK-8371413 and we will
investigate.

A couple of question though:

1. if I understand correctly the server was using a self-signed
    certificate and the client truststore didn't contain it. Is
    that a fair description of the set up?

2. would it possible for you to share the client logs when the issue
    occurred?

    Running the client with:
 
-Ddk.httpclient.HttpClient.log=requests,headers,errors,http3,quic:control:retransmit

    would help us diagnose the issue.

Note: the mailing list might reject the attachment, let me know if
       that happens.

best regards,

-- daniel

On 06/11/2025 15:15, Josiah Noel wrote:
> I've been testing the?Http3 support on windows 11 with?build 
> 26-ea+22-2263, and my request was seemingly just timing out.
> 
> After like 3 hours of fiddling, I realized that I forgot to import the 
> mkcert rootCA? I was using into the jdk cacerts.
> 
> Long story short, when I ran? `keytool -import -trustcacerts -noprompt 
> -alias mkcert-root-ca ? -file "$(mkcert -CAROOT)/rootCA.pem" ? -keystore 
> "$JAVA_HOME/lib/security/cacerts" ? -storepass changeit` then it 
> suddenly began to work.
> 
> Perchance is it possible to get a clearer error message?


From daniel.fuchs at oracle.com  Thu Nov  6 15:41:26 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 6 Nov 2025 15:41:26 +0000
Subject: (offlist) Re: Http3 Client times out for an untrusted certificate
In-Reply-To: <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
Message-ID: <26fcc1e4-fc20-48fb-9c14-d50d79d538dd@oracle.com>

On 06/11/2025 15:37, Daniel Fuchs wrote:
> Hi Joshua,

My apologies for mistyping your first name Josiah.

I'll proof read my response twice before pressing `send` next time.

best regards,

-- daniel


From jaikiran.pai at oracle.com  Thu Nov  6 15:43:12 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Thu, 6 Nov 2025 21:13:12 +0530
Subject: Http3 Client times out for an untrusted certificate
In-Reply-To: <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
Message-ID: <216da9f5-c89f-4d3e-909c-c798f75a945a@oracle.com>

In addition to what Daniel noted, could you also show us the snippet of 
the client application code which was issuing this request? Was it using 
any Http3DiscoveryMode? And to be clear, the application wasn't 
receiving any exception, not even any timeout exception?

-Jaikiran

On 06/11/25 9:07 pm, Daniel Fuchs wrote:
> Hi Joshua,
>
> Thanks for reporting this and for trying out HTTP/3!
>
> I have logged https://bugs.openjdk.org/browse/JDK-8371413 and we will
> investigate.
>
> A couple of question though:
>
> 1. if I understand correctly the server was using a self-signed
> ?? certificate and the client truststore didn't contain it. Is
> ?? that a fair description of the set up?
>
> 2. would it possible for you to share the client logs when the issue
> ?? occurred?
>
> ?? Running the client with:
>
> -Ddk.httpclient.HttpClient.log=requests,headers,errors,http3,quic:control:retransmit 
>
>
> ?? would help us diagnose the issue.
>
> Note: the mailing list might reject the attachment, let me know if
> ????? that happens.
>
> best regards,
>
> -- daniel
>
> On 06/11/2025 15:15, Josiah Noel wrote:
>> I've been testing the?Http3 support on windows 11 with?build 
>> 26-ea+22-2263, and my request was seemingly just timing out.
>>
>> After like 3 hours of fiddling, I realized that I forgot to import 
>> the mkcert rootCA? I was using into the jdk cacerts.
>>
>> Long story short, when I ran? `keytool -import -trustcacerts 
>> -noprompt -alias mkcert-root-ca ? -file "$(mkcert 
>> -CAROOT)/rootCA.pem" ? -keystore "$JAVA_HOME/lib/security/cacerts" ? 
>> -storepass changeit` then it suddenly began to work.
>>
>> Perchance is it possible to get a clearer error message?
>

From dfuchs at openjdk.org  Thu Nov  6 15:53:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 15:53:10 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v4]
In-Reply-To: <LcMIBTb-AwN67zFLEn93RAxoOUG6GI0Q7Vgi4vSa9us=.81088c86-8e0a-4bff-bdcd-bfb0d7b7ba3e@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <LcMIBTb-AwN67zFLEn93RAxoOUG6GI0Q7Vgi4vSa9us=.81088c86-8e0a-4bff-bdcd-bfb0d7b7ba3e@github.com>
Message-ID: <biBDswcs2EdYohKt0G5pYsdbrl4xibmXvfGxwduDWVo=.c1c30988-e056-4b6b-8394-c264d2331070@github.com>

On Tue, 4 Nov 2025 11:37:13 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
>> 
>> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
>> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
>> 
>> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
>> 
>> Currently, only POST(), PUT(), and method() include these messages.
>> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
>> I would like to discuss whether adding consistent messages to those methods would be beneficial,
>> and whether the current wording "BodyPublisher must not be null" feels appropriate.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371091: Add testNullMessages() to HttpRequestBuilderTest and fix whitespaces error

I ran HttpClient tests in the CI and they came back green. 
So look good to  me!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28103#pullrequestreview-3428977186

From duke at openjdk.org  Thu Nov  6 15:57:01 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Nov 2025 15:57:01 GMT
Subject: RFR: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder [v4]
In-Reply-To: <LcMIBTb-AwN67zFLEn93RAxoOUG6GI0Q7Vgi4vSa9us=.81088c86-8e0a-4bff-bdcd-bfb0d7b7ba3e@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
 <LcMIBTb-AwN67zFLEn93RAxoOUG6GI0Q7Vgi4vSa9us=.81088c86-8e0a-4bff-bdcd-bfb0d7b7ba3e@github.com>
Message-ID: <DAysqSvBgGXmGo7AzR3X8jlKolkPmDe2Wj5UD5xDwUU=.5425ae88-9f8a-4232-9449-14faa61f11e5@github.com>

On Tue, 4 Nov 2025 11:37:13 GMT, EunHyunsu <duke at openjdk.org> wrote:

>> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
>> 
>> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
>> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
>> 
>> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
>> 
>> Currently, only POST(), PUT(), and method() include these messages.
>> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
>> I would like to discuss whether adding consistent messages to those methods would be beneficial,
>> and whether the current wording "BodyPublisher must not be null" feels appropriate.
>
> EunHyunsu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8371091: Add testNullMessages() to HttpRequestBuilderTest and fix whitespaces error

@ehs208 
Your change (at version f26cc336c878e18757e996b95e983cbaca8a0ce4) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28103#issuecomment-3497986860

From dfuchs at openjdk.org  Thu Nov  6 15:57:02 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 15:57:02 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v10]
In-Reply-To: <ICyJ_i-UQRqFLfbWC9A0IAEUmV25E5pA-dLDIR1OCJI=.3d233b06-7a05-46b9-aacd-8a035e05c2aa@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <DftS9vAGN9eo6OC7uNzjZNFkra4Lp3WDpwuNAHOuTEM=.8894558e-f909-4f1e-880e-94363c5edc40@github.com>
 <fnWh2iF9gm10kcgbAuvuxdSOdzW8BG8iuoUq4J01J58=.2cca6ca3-76f2-4c80-9ef1-7a370ac36ae6@github.com>
 <ICyJ_i-UQRqFLfbWC9A0IAEUmV25E5pA-dLDIR1OCJI=.3d233b06-7a05-46b9-aacd-8a035e05c2aa@github.com>
Message-ID: <OjA4lhfj51Z8TADrKc7I8C7Eu5M1Ws749zvMj-phGTw=.a1307fdc-6fa7-41cf-99d6-9d699fd4fc40@github.com>

On Thu, 6 Nov 2025 13:15:59 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/websocket/WebSocketTest.java line 172:
>> 
>>> 170:                         .newWebSocketBuilder()
>>> 171:                         .buildAsync(server.getURI(), webSocketListener)
>>> 172:                         .join();
>> 
>> Shouldn't you add a `connectTimeout` to the web socket builder? Otherwise of course you won't find any :-)
>
> I was naively expecting `WebSocket.Builder` to inherit `connectTimeout` from the parent `HttpClient`, I was indeed mistaken. Corrected it in c3210d88d0c.

Well the connect timeout if set in the client *is* inherited, but it only concerns TCP/TLS and stops after the SSL handshake.
The WebSocket connect timeout additionally covers the WebSocket handshake - and stops when the 101 response is received.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2499601626

From dfuchs at openjdk.org  Thu Nov  6 16:11:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 16:11:32 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v11]
In-Reply-To: <LRmk6VTU3tyNUpz-c0aE0PMcY5XZxIBqywiI2L2XR-k=.de32039d-a5d7-4304-9e25-c4daf9886097@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <LRmk6VTU3tyNUpz-c0aE0PMcY5XZxIBqywiI2L2XR-k=.de32039d-a5d7-4304-9e25-c4daf9886097@github.com>
Message-ID: <8gEPtGRUveHAPt1A3gCD3wV1_9abcIV0Zjsm6_bRMos=.f90f431e-85f7-45ab-b9af-acb7f9bd2f53@github.com>

On Thu, 6 Nov 2025 13:19:26 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Configure timeout for the `WebSocketTest`
>  - Use `var`

src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 391:

> 389:             // Ensure that the connection is closed or returned to the pool
> 390:             exch.nullBody(response, throwable);
> 391:         });

This might not be the correct place. Shouldn't we instead call `cancelTimer()` as soon as we know there won't be a body, after line 405 below, so that we are sure the timer is cancelled even in the case where a body not permitted is present?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2499671514

From duke at openjdk.org  Thu Nov  6 16:16:55 2025
From: duke at openjdk.org (EunHyunsu)
Date: Thu, 6 Nov 2025 16:16:55 GMT
Subject: Integrated: 8371091: Improve the exception message of
 NullPointerException thrown by the methods in the default implementation of
 HttpRequest.Builder
In-Reply-To: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
References: <PH9UUPvBM10GOspmE4fH5YD9W4cwOyFNI8daXgRqoCU=.1e9a6d96-6d16-4566-b616-cc62fb593774@github.com>
Message-ID: <r9uaFlFn9bSdbhpcUQIkeUMwRg8eejR7e_UDBl2Rf-s=.74b8c8a5-4743-4fb7-9037-f03ee37db7b9@github.com>

On Sun, 2 Nov 2025 07:19:12 GMT, EunHyunsu <duke at openjdk.org> wrote:

> This change adds clearer NullPointerException messages to the POST(), PUT(), and method() methods in HttpRequest.Builder when the provided BodyPublisher is null.
> 
> Each of these methods now calls `requireNonNull(body, "BodyPublisher must not be null")`, making the exception message explicit.
> A corresponding regression test (RequestBuilderNullBodyTest) has been added to verify this behavior.
> 
> All builds and related tests (jdk/java/net/httpclient) have passed successfully.
> 
> Currently, only POST(), PUT(), and method() include these messages.
> Some other builder methods (such as header(), setHeader()) also throw NullPointerException without a message.
> I would like to discuss whether adding consistent messages to those methods would be beneficial,
> and whether the current wording "BodyPublisher must not be null" feels appropriate.

This pull request has now been integrated.

Changeset: c272aca8
Author:    EunHyunsu <ehs208 at naver.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c272aca8a0a2720365159684bed35c0c31e8778f
Stats:     41 lines in 2 files changed: 37 ins; 0 del; 4 mod

8371091: Improve the exception message of NullPointerException thrown by the methods in the default implementation of HttpRequest.Builder

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28103

From dfuchs at openjdk.org  Thu Nov  6 16:29:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 16:29:11 GMT
Subject: RFR: 8371366: java/net/httpclient/whitebox/RawChannelTestDriver.java
 fails intermittently in jtreg timeout
Message-ID: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>

Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.

The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

-------------

Commit messages:
 - 8371366: java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in jtreg timeout

Changes: https://git.openjdk.org/jdk/pull/28178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371366
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28178/head:pull/28178

PR: https://git.openjdk.org/jdk/pull/28178

From josiahnoel at gmail.com  Thu Nov  6 16:52:49 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Thu, 6 Nov 2025 11:52:49 -0500
Subject: Http3 Client times out for an untrusted certificate
In-Reply-To: <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
Message-ID: <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>

Indeed I'm using a self signed cert created by mkcert for the server. I
created a keystore out of it, and used the same sslcontext for both the
server and the client. Attached are my logs.



On Thu, Nov 6, 2025 at 10:38?AM Daniel Fuchs <daniel.fuchs at oracle.com>
wrote:

> Hi Joshua,
>
> Thanks for reporting this and for trying out HTTP/3!
>
> I have logged https://bugs.openjdk.org/browse/JDK-8371413 and we will
> investigate.
>
> A couple of question though:
>
> 1. if I understand correctly the server was using a self-signed
>     certificate and the client truststore didn't contain it. Is
>     that a fair description of the set up?
>
> 2. would it possible for you to share the client logs when the issue
>     occurred?
>
>     Running the client with:
>
>
> -Ddk.httpclient.HttpClient.log=requests,headers,errors,http3,quic:control:retransmit
>
>     would help us diagnose the issue.
>
> Note: the mailing list might reject the attachment, let me know if
>        that happens.
>
> best regards,
>
> -- daniel
>
> On 06/11/2025 15:15, Josiah Noel wrote:
> > I've been testing the Http3 support on windows 11 with build
> > 26-ea+22-2263, and my request was seemingly just timing out.
> >
> > After like 3 hours of fiddling, I realized that I forgot to import the
> > mkcert rootCA  I was using into the jdk cacerts.
> >
> > Long story short, when I ran  `keytool -import -trustcacerts -noprompt
> > -alias mkcert-root-ca   -file "$(mkcert -CAROOT)/rootCA.pem"   -keystore
> > "$JAVA_HOME/lib/security/cacerts"   -storepass changeit` then it
> > suddenly began to work.
> >
> > Perchance is it possible to get a clearer error message?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251106/12fb391c/attachment.htm>
-------------- next part --------------
WARNING: Unknown module: io.avaje.jex.test specified to --add-reads
Nov 06, 2025 11:37:03 AM io.avaje.jex.core.BootstrapServer start
INFO: Avaje Jex started class io.avaje.jex.http3.flupke.impl.FlupkeHttpServer in 194ms on https://0:0:0:0:0:0:0:0:8080
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.Http3ClientImpl getConnectionFor
INFO: HTTP3: getConnectionFor exchange https://localhost:8080 GET #1
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.Http3ClientImpl getConnectionFor
INFO: HTTP3: Creating connection for Exchange https://localhost:8080 GET #1
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.HttpQuicConnection logAltSvcFor
INFO: ALTSVC: No AltService found for localhost:8080
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.QuicClient chooseEndpoint
INFO: QUIC: Adding new endpoint: QuicEndpoint(HttpClientImpl(1)-0)
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.QuicEndpoint lambda$create$1
INFO: QUIC: Initial receive buffer size is: 65536
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.QuicEndpoint lambda$create$1
INFO: QUIC: Initial send buffer size is: 65536
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.Http3Connection createAsync
INFO: HTTP3: Http3Connection.createAsync: Got HttpQuicConnection for https://localhost:8080 GET #1 is: quic:1
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.QuicConnectionImpl startInitialTimer
INFO: QUIC: QuicClientConnection(1): Arming quic initial timer for PT29.9998017S
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.QuicConnectionImpl sendFirstInitialPacket
INFO: QUIC: QuicClientConnection(1): connectionId: a2185e4ac3afe4deda4fc7dc14, QuicEndpoint(HttpClientImpl(1)-0): QuicEndpoint(HttpClientImpl(1)-0) - /[0:0:0:0:0:0:0:0]:50781
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.IdleTimeoutManager checkUpdateIdleTimeout
INFO: QUIC: QuicClientConnection(1) idle connection timeout updated to 30,000 milli seconds
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): INITIAL no deadline, task unscheduled
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space INITIAL
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.ConnectionTerminatorImpl immediateClose
INFO: QUIC: QuicClientConnection(1) entering closing state, code 0x12e - jdk.internal.net.quic.QuicTransportException: certificate_unknown
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.QuicConnectionImpl pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: HANDSHAKE(pn:2, size=70, frames:[ConnectionCloseFrame[type=0x1c, errorCode=0x12e, tlsAlertDescription=46, errorFrameType=0x0, reason=certificate_unknown]])
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space HANDSHAKE
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space APPLICATION
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.Http3ClientImpl connectionCompleted
INFO: HTTP3: Checking waiters on completed connection null to https:localhost:8080 created for https://localhost:8080 GET #1
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): HANDSHAKE no deadline, task unscheduled
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task unscheduled
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.quic.ConnectionTerminatorImpl immediateClose
INFO: QUIC: QuicClientConnection(1) connection has now transitioned to closing state
Nov 06, 2025 11:37:04 AM jdk.internal.net.http.Http3ClientImpl connectionCompleted0
INFO: HTTP3: No HTTP/3 connection created for requests to https:localhost:8080, will fail or downgrade: waiters[0](completed:0, retried:0, errors:0) - originally created for https://localhost:8080 GET #1

From msheppar at openjdk.org  Thu Nov  6 17:25:20 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Thu, 6 Nov 2025 17:25:20 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <f0l8kDZ7H8dozkgFl8sQZgkJcCWcEfdadSSxm1Fpij4=.b4cb4bf7-3588-4520-9950-3446db2e1312@github.com>

On Thu, 6 Nov 2025 16:22:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

a FYI on this timeout ... current timeout factor == 4 i.e. test timeout is 120 * 4 == 480 seconds
as per test log
 -J-Dtest.timeout.factor=4.0

so you are effectively increasing from 120 * 4  to 240 * 4

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3498472889

From dfuchs at openjdk.org  Thu Nov  6 18:08:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 6 Nov 2025 18:08:49 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <6GESBgxXyGMM-Z4JULHL9j3A9GyCWyyk8hHC1nujUh4=.cae22bbc-cdd3-4c09-a077-cf6c98232a66@github.com>

On Thu, 6 Nov 2025 16:22:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

Yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3498689268

From daniel.fuchs at oracle.com  Thu Nov  6 18:41:04 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 6 Nov 2025 18:41:04 +0000
Subject: [External] : Re: Http3 Client times out for an untrusted
 certificate
In-Reply-To: <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
 <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
Message-ID: <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>

Hi Josiah,

When trying the same (I modified H3SimpleTest to not pass
the SSLContext to the client, and tried various configuration
with setting HTTP/3 on either the HttpRequest or client or both),
I always get an exception of the form shown below.

What result did you get? Didn't you get any exception, or maybe
a different exception?

javax.net.ssl.SSLHandshakeException: QUIC connection establishment failed
	at 
java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:1008)
	at 
java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133)
	at H3SimpleTest.testBasicRequests(H3SimpleTest.java:116)
         ...
Caused by: javax.net.ssl.SSLHandshakeException: QUIC connection 
establishment failed
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow.sslHandshakeException(QuicConnectionImpl.java:608)
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow.failHandshakeCFs(QuicConnectionImpl.java:593)
	at 
java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.failHandshakeCFs(ConnectionTerminatorImpl.java:368)
	at 
java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.failHandshakeCFs(ConnectionTerminatorImpl.java:363)
	at 
java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.immediateClose(ConnectionTerminatorImpl.java:257)
	at 
java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.doTerminate(ConnectionTerminatorImpl.java:128)
	at 
java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.terminate(ConnectionTerminatorImpl.java:86)
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.processHandshakePacket(QuicConnectionImpl.java:2403)
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.processDecrypted(QuicConnectionImpl.java:1965)
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.decrypt(QuicConnectionImpl.java:741)
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.internalProcessIncoming(QuicConnectionImpl.java:1899)
	at 
java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.incoming(QuicConnectionImpl.java:701)
	at 
java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182)
	at 
java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
	at 
java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
	at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	... 1 more
Caused by: java.io.IOException: certificate_unknown
	at 
java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:131)
	at 
java.net.http/jdk.internal.net.http.quic.TerminationCause.<init>(TerminationCause.java:49)
	at 
java.net.http/jdk.internal.net.http.quic.TerminationCause$TransportError.<init>(TerminationCause.java:151)
	at 
java.net.http/jdk.internal.net.http.quic.TerminationCause.forException(TerminationCause.java:102)
	... 11 more


On 06/11/2025 16:52, Josiah Noel wrote:
> Indeed I'm using a self signed cert created by mkcert for the server. I 
> created a keystore out of it, and used the same sslcontext for both the 
> server and the client. Attached are my logs.


From josiahnoel at gmail.com  Thu Nov  6 21:04:27 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Thu, 6 Nov 2025 16:04:27 -0500
Subject: [External] : Re: Http3 Client times out for an untrusted
 certificate
In-Reply-To: <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
 <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
 <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>
Message-ID: <CAJ_t5Ub6bKxRmYcek1yLch0huwtpGWjex6PDEiUKEQUjKNXzFg@mail.gmail.com>

I haven't faced any such exception, give me some time and I'll extract a
minimal example with steps to reproduce the problem.

On Thu, Nov 6, 2025 at 1:41?PM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi Josiah,
>
> When trying the same (I modified H3SimpleTest to not pass
> the SSLContext to the client, and tried various configuration
> with setting HTTP/3 on either the HttpRequest or client or both),
> I always get an exception of the form shown below.
>
> What result did you get? Didn't you get any exception, or maybe
> a different exception?
>
> javax.net.ssl.SSLHandshakeException: QUIC connection establishment failed
>         at
>
> java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:1008)
>         at
>
> java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133)
>         at H3SimpleTest.testBasicRequests(H3SimpleTest.java:116)
>          ...
> Caused by: javax.net.ssl.SSLHandshakeException: QUIC connection
> establishment failed
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow.sslHandshakeException(QuicConnectionImpl.java:608)
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow.failHandshakeCFs(QuicConnectionImpl.java:593)
>         at
>
> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.failHandshakeCFs(ConnectionTerminatorImpl.java:368)
>         at
>
> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.failHandshakeCFs(ConnectionTerminatorImpl.java:363)
>         at
>
> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.immediateClose(ConnectionTerminatorImpl.java:257)
>         at
>
> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.doTerminate(ConnectionTerminatorImpl.java:128)
>         at
>
> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.terminate(ConnectionTerminatorImpl.java:86)
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.processHandshakePacket(QuicConnectionImpl.java:2403)
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.processDecrypted(QuicConnectionImpl.java:1965)
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.decrypt(QuicConnectionImpl.java:741)
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.internalProcessIncoming(QuicConnectionImpl.java:1899)
>         at
>
> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.incoming(QuicConnectionImpl.java:701)
>         at
>
> java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182)
>         at
>
> java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
>         at
>
> java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
>         at
>
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
>         at
>
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
>         ... 1 more
> Caused by: java.io.IOException: certificate_unknown
>         at
>
> java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:131)
>         at
>
> java.net.http/jdk.internal.net.http.quic.TerminationCause.<init>(TerminationCause.java:49)
>         at
>
> java.net.http/jdk.internal.net.http.quic.TerminationCause$TransportError.<init>(TerminationCause.java:151)
>         at
>
> java.net.http/jdk.internal.net.http.quic.TerminationCause.forException(TerminationCause.java:102)
>         ... 11 more
>
>
> On 06/11/2025 16:52, Josiah Noel wrote:
> > Indeed I'm using a self signed cert created by mkcert for the server. I
> > created a keystore out of it, and used the same sslcontext for both the
> > server and the client. Attached are my logs.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251106/6e81ad8b/attachment-0001.htm>

From josiahnoel at gmail.com  Fri Nov  7 00:55:04 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Thu, 6 Nov 2025 19:55:04 -0500
Subject: [External] : Re: Http3 Client times out for an untrusted
 certificate
In-Reply-To: <CAJ_t5Ub6bKxRmYcek1yLch0huwtpGWjex6PDEiUKEQUjKNXzFg@mail.gmail.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
 <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
 <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>
 <CAJ_t5Ub6bKxRmYcek1yLch0huwtpGWjex6PDEiUKEQUjKNXzFg@mail.gmail.com>
Message-ID: <CAJ_t5Uab7ADKHtuz4gaL6UG9hD_8zxUZOAQh5-qmkgmMuKHuQQ@mail.gmail.com>

It seems that this issue only manifests itself when an httpserver is
running tcp on the same port. Attached is a jbang script that illustrates
this issue.

On Thu, Nov 6, 2025 at 4:04?PM Josiah Noel <josiahnoel at gmail.com> wrote:

> I haven't faced any such exception, give me some time and I'll extract a
> minimal example with steps to reproduce the problem.
>
> On Thu, Nov 6, 2025 at 1:41?PM Daniel Fuchs <daniel.fuchs at oracle.com>
> wrote:
>
>> Hi Josiah,
>>
>> When trying the same (I modified H3SimpleTest to not pass
>> the SSLContext to the client, and tried various configuration
>> with setting HTTP/3 on either the HttpRequest or client or both),
>> I always get an exception of the form shown below.
>>
>> What result did you get? Didn't you get any exception, or maybe
>> a different exception?
>>
>> javax.net.ssl.SSLHandshakeException: QUIC connection establishment failed
>>         at
>>
>> java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:1008)
>>         at
>>
>> java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133)
>>         at H3SimpleTest.testBasicRequests(H3SimpleTest.java:116)
>>          ...
>> Caused by: javax.net.ssl.SSLHandshakeException: QUIC connection
>> establishment failed
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow.sslHandshakeException(QuicConnectionImpl.java:608)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow.failHandshakeCFs(QuicConnectionImpl.java:593)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.failHandshakeCFs(ConnectionTerminatorImpl.java:368)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.failHandshakeCFs(ConnectionTerminatorImpl.java:363)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.immediateClose(ConnectionTerminatorImpl.java:257)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.doTerminate(ConnectionTerminatorImpl.java:128)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.ConnectionTerminatorImpl.terminate(ConnectionTerminatorImpl.java:86)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.processHandshakePacket(QuicConnectionImpl.java:2403)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.processDecrypted(QuicConnectionImpl.java:1965)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.decrypt(QuicConnectionImpl.java:741)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.internalProcessIncoming(QuicConnectionImpl.java:1899)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.QuicConnectionImpl.incoming(QuicConnectionImpl.java:701)
>>         at
>>
>> java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182)
>>         at
>>
>> java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
>>         at
>>
>> java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
>>         at
>>
>> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
>>         at
>>
>> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
>>         ... 1 more
>> Caused by: java.io.IOException: certificate_unknown
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:131)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.TerminationCause.<init>(TerminationCause.java:49)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.TerminationCause$TransportError.<init>(TerminationCause.java:151)
>>         at
>>
>> java.net.http/jdk.internal.net.http.quic.TerminationCause.forException(TerminationCause.java:102)
>>         ... 11 more
>>
>>
>> On 06/11/2025 16:52, Josiah Noel wrote:
>> > Indeed I'm using a self signed cert created by mkcert for the server. I
>> > created a keystore out of it, and used the same sslcontext for both the
>> > server and the client. Attached are my logs.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251106/0dd4dbff/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UntrustedHttp3.java
Type: application/octet-stream
Size: 3306 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251106/0dd4dbff/UntrustedHttp3.java>

From vyazici at openjdk.org  Fri Nov  7 08:19:13 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 08:19:13 GMT
Subject: RFR: 8366577: Deprecate java.net.Socket::setPerformancePreferences
 [v3]
In-Reply-To: <3MKlB8kYKmJ7ZLwmhrIRYdVV7URoXFjr_EOdAByB-FU=.c1e05ed0-10f6-4ccd-af55-418ea417114d@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
 <j-MQNksF9YCAKdt8M7qChZ8QIkPjxfkrjPHAAyIqLVU=.ed91ff66-7c6e-49cd-b4e5-73b1daf47e46@github.com>
 <3MKlB8kYKmJ7ZLwmhrIRYdVV7URoXFjr_EOdAByB-FU=.c1e05ed0-10f6-4ccd-af55-418ea417114d@github.com>
Message-ID: <5lFkd83GWOyxNKMFhlYafqWpv3Zlp1YixpHastNIPsE=.9d6113f5-fee1-49d8-8659-9b3acb49eb50@github.com>

On Wed, 5 Nov 2025 11:51:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Shorten `@deprecated` message
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman, @dfuch, @jaikiran, thanks so much for the reviews.

Tier 1-2 is clear on 50826c3e099 ? succeeding commits were simple JavaDoc updates, hence not issuing another CI run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28129#issuecomment-3501218485

From vyazici at openjdk.org  Fri Nov  7 08:19:14 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 08:19:14 GMT
Subject: Integrated: 8366577: Deprecate
 java.net.Socket::setPerformancePreferences
In-Reply-To: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
References: <mGL-hPwaaKxbrPp0fSeDjpFI1RfMldEueA15oOmuarw=.2262c392-dca4-4bdc-a660-72dd412364e8@github.com>
Message-ID: <WumKF45ABlN9Uq4lrv1xuv0KhH7-irfMWF0eDuFGjdA=.226348f1-392d-4ae0-a574-e8735fcb89ae@github.com>

On Tue, 4 Nov 2025 10:53:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> `java.net.Socket::setPerformancePreferences` was introduced in Java 1.5 with the intention of providing a declarative API for configuring the performance-wise characteristics of the underlying socket. It has always been a no-op and a corpus search does not reveal any significant usages of it. Recently merged [JDK-8366575] removes the SDP (Sockets Direct Protocol) support, and this further undermines the value of `setPerformancePreferences`. This PR deprecates `setPerformancePreferences` and friends _for removal_.
> 
> [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575

This pull request has now been integrated.

Changeset: 866faa9d
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/866faa9d40ab336e4c4861a55edc4c91d8aa0c74
Stats:     14 lines in 4 files changed: 13 ins; 0 del; 1 mod

8366577: Deprecate java.net.Socket::setPerformancePreferences

Reviewed-by: dfuchs, alanb, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28129

From vyazici at openjdk.org  Fri Nov  7 08:28:11 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 08:28:11 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v11]
In-Reply-To: <8gEPtGRUveHAPt1A3gCD3wV1_9abcIV0Zjsm6_bRMos=.f90f431e-85f7-45ab-b9af-acb7f9bd2f53@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <LRmk6VTU3tyNUpz-c0aE0PMcY5XZxIBqywiI2L2XR-k=.de32039d-a5d7-4304-9e25-c4daf9886097@github.com>
 <8gEPtGRUveHAPt1A3gCD3wV1_9abcIV0Zjsm6_bRMos=.f90f431e-85f7-45ab-b9af-acb7f9bd2f53@github.com>
Message-ID: <-ixnshakO8f7lzts65WM2LXcjmFYGxMknHYZsEMlGPk=.ca4d034b-99de-42cd-9082-fcf326446fe1@github.com>

On Thu, 6 Nov 2025 16:07:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> after line 405 below

@dfuch, do you mean right after the `if (bodyNotPermitted(r)) {` line? (Sorry, I find line numbers difficult to track in the flux of changes.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2502103562

From daniel.fuchs at oracle.com  Fri Nov  7 09:46:10 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 7 Nov 2025 09:46:10 +0000
Subject: [External] : Re: Http3 Client times out for an untrusted
 certificate
In-Reply-To: <CAJ_t5Uab7ADKHtuz4gaL6UG9hD_8zxUZOAQh5-qmkgmMuKHuQQ@mail.gmail.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
 <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
 <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>
 <CAJ_t5Ub6bKxRmYcek1yLch0huwtpGWjex6PDEiUKEQUjKNXzFg@mail.gmail.com>
 <CAJ_t5Uab7ADKHtuz4gaL6UG9hD_8zxUZOAQh5-qmkgmMuKHuQQ@mail.gmail.com>
Message-ID: <0ea5402d-da08-4ac8-9c9c-18965333e6c6@oracle.com>

Hi Josiah,

On 07/11/2025 00:55, Josiah Noel wrote:
> It seems that this issue only manifests itself when an?httpserver is 
> running tcp on the same port. Attached is a jbang script that 
> illustrates this issue.

Oh - but I had tried that too - and I got the `certificate_unknown`
from the tcp server that time:

Caused by: javax.net.ssl.SSLHandshakeException: (certificate_unknown) 
PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to 
find valid certification path to requested target
	at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:130)
	at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:376)
	at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:319)
	at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:314)
	at 
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1310)
	at 
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.onConsumeCertificate(CertificateMessage.java:1172)
	at 
java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.consume(CertificateMessage.java:1115)
	at java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:421)
	at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:477)
	at 
java.base/sun.security.ssl.SSLEngineImpl$DelegatedTask.run(SSLEngineImpl.java:1207)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1604)
	at 
java.net.http/jdk.internal.net.http.common.SSLFlowDelegate.lambda$executeTasks$0(SSLFlowDelegate.java:1148)
	at 
java.net.http/jdk.internal.net.http.HttpClientImpl$DelegatingExecutor.execute(HttpClientImpl.java:188)
	at 
java.net.http/jdk.internal.net.http.common.SSLFlowDelegate.executeTasks(SSLFlowDelegate.java:1143)
	at 
java.net.http/jdk.internal.net.http.common.SSLFlowDelegate.doHandshake(SSLFlowDelegate.java:1109)
	at 
java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader.processData(SSLFlowDelegate.java:508)
	at 
java.net.http/jdk.internal.net.http.common.SSLFlowDelegate$Reader$ReaderDownstreamPusher.run(SSLFlowDelegate.java:283)
	at 
java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182)
	at 
java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
	at 
java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
	at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	... 1 more

Does the server supports https? Because if the server does not
support https it might just be trying to read the request line
before responding, and the client might be waiting for the server
hello. The same would happen with HTTP/1.1 if you tried to use
https with a server that only supports http.

I will try your script and investigate further.

When only specifying HTTP/3 the client will try both Quic and TCP
and fallback to TCP if Quic fails.

It's possible to change that behaviour by specifying an H3_DISCOVERY
option at the request level.

Jaikiran wrote a very good article which explains that:
https://inside.java/2025/10/22/http3-support/

cheers,

-- daniel


From dfuchs at openjdk.org  Fri Nov  7 09:55:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 09:55:05 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v11]
In-Reply-To: <-ixnshakO8f7lzts65WM2LXcjmFYGxMknHYZsEMlGPk=.ca4d034b-99de-42cd-9082-fcf326446fe1@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <LRmk6VTU3tyNUpz-c0aE0PMcY5XZxIBqywiI2L2XR-k=.de32039d-a5d7-4304-9e25-c4daf9886097@github.com>
 <8gEPtGRUveHAPt1A3gCD3wV1_9abcIV0Zjsm6_bRMos=.f90f431e-85f7-45ab-b9af-acb7f9bd2f53@github.com>
 <-ixnshakO8f7lzts65WM2LXcjmFYGxMknHYZsEMlGPk=.ca4d034b-99de-42cd-9082-fcf326446fe1@github.com>
Message-ID: <Pl7BWOqK_lDFWbMrJs44yBBRN8U9AaGQkq_Q5TbBz5A=.ba033cae-c629-4052-ae66-d248c72b4723@github.com>

On Fri, 7 Nov 2025 08:25:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 391:
>> 
>>> 389:             // Ensure that the connection is closed or returned to the pool
>>> 390:             exch.nullBody(response, throwable);
>>> 391:         });
>> 
>> This might not be the correct place. Shouldn't we instead call `cancelTimer()` as soon as we know there won't be a body, after line 405 below, so that we are sure the timer is cancelled even in the case where a body not permitted is present?
>
>> after line 405 below
> 
> @dfuch, do you mean right after the `if (bodyNotPermitted(r)) {` line? (Sorry, I find line numbers difficult to track in the flux of changes.)

if (bodyNotPermitted(r)) {
                            if (bodyIsPresent(r)) {

between these two lines :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2502458076

From daniel.fuchs at oracle.com  Fri Nov  7 11:56:21 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 7 Nov 2025 11:56:21 +0000
Subject: [External] : Re: Http3 Client times out for an untrusted
 certificate
In-Reply-To: <0ea5402d-da08-4ac8-9c9c-18965333e6c6@oracle.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
 <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
 <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>
 <CAJ_t5Ub6bKxRmYcek1yLch0huwtpGWjex6PDEiUKEQUjKNXzFg@mail.gmail.com>
 <CAJ_t5Uab7ADKHtuz4gaL6UG9hD_8zxUZOAQh5-qmkgmMuKHuQQ@mail.gmail.com>
 <0ea5402d-da08-4ac8-9c9c-18965333e6c6@oracle.com>
Message-ID: <14a2ffb7-4d29-4179-a8fe-dcabe49fba81@oracle.com>

Hi Josiah,

On 07/11/2025 09:46, Daniel Fuchs wrote:
> Does the server supports https? Because if the server does not
> support https it might just be trying to read the request line
> before responding, and the client might be waiting for the server
> hello. The same would happen with HTTP/1.1 if you tried to use
> https with a server that only supports http.

So that seems to be the issue.
I had a look at your script - and I believe that if
you had used HttpsServer.create() instead of HttpServer.create()
you would have got the exception as expected.

I am not sure there's much we can do there. If you try to send
an HTTP/1.1 https:// request to that server youn will observe
the same behavior.

Specifically try this:

```
     // http1 server on tcp 8080
     // btw what if we made a conveniece method? I'll contribute it 
myself, just say the word
     var http1 = HttpServer.create(new InetSocketAddress(8080), 0);
     http1.createContext("/", ctx -> ctx.sendResponseHeaders(101, -1));
     http1.start();

     var client = HttpClient.newBuilder()
	.version(HttpClient.Version.HTTP_1_1)
	.build();
     var request = HttpRequest.newBuilder()
	.uri(URI.create("https://localhost:8080/"))
	.build();
     System.out.println("req: " + request);
     var resp = client.send(request, HttpResponse.BodyHandlers.ofString());
     System.out.println("resp: " + resp);
```

This has the same behaviour and does not involve HTTP/3.
To see the exception, add this to the request in your
original script:

```
import java.net.http.HttpOption;
import static java.net.http.HttpOption.H3_DISCOVERY;
import static java.net.http.HttpOption.Http3DiscoveryMode.HTTP_3_URI_ONLY;

...

      HttpRequest.newBuilder().uri(URI.create("https://localhost:8080"))
         .setOption(H3_DISCOVERY, HTTP_3_URI_ONLY)   <<<<< HTTP/3 only
         .GET().build(),
```

this will prevent the client from falling back to TCP.

best regards,

-- daniel


From josiahnoel at gmail.com  Fri Nov  7 12:43:31 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Fri, 7 Nov 2025 07:43:31 -0500
Subject: [External] : Re: Http3 Client times out for an untrusted
 certificate
In-Reply-To: <14a2ffb7-4d29-4179-a8fe-dcabe49fba81@oracle.com>
References: <CAJ_t5Uat5XYmOeAKoV9P=pOfybMBJQn5vb0myURqk615e-VbQQ@mail.gmail.com>
 <49dffe53-f265-4e97-89f6-3c873a7bd618@oracle.com>
 <CAJ_t5UaMzx6jeYmvi9EGB8JAy1Vv7b6gDHQPEed6-3DnAuZTFQ@mail.gmail.com>
 <e4be8d1d-76ee-414f-882f-da460a01b037@oracle.com>
 <CAJ_t5Ub6bKxRmYcek1yLch0huwtpGWjex6PDEiUKEQUjKNXzFg@mail.gmail.com>
 <CAJ_t5Uab7ADKHtuz4gaL6UG9hD_8zxUZOAQh5-qmkgmMuKHuQQ@mail.gmail.com>
 <0ea5402d-da08-4ac8-9c9c-18965333e6c6@oracle.com>
 <14a2ffb7-4d29-4179-a8fe-dcabe49fba81@oracle.com>
Message-ID: <CAJ_t5UaPL1zM7N2ib1jfAKJV6j1S21oqdwSMoirBKOvg1qbF8g@mail.gmail.com>

I see, thanks for looking into it.

On Fri, Nov 7, 2025, 6:56?AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Hi Josiah,
>
> On 07/11/2025 09:46, Daniel Fuchs wrote:
> > Does the server supports https? Because if the server does not
> > support https it might just be trying to read the request line
> > before responding, and the client might be waiting for the server
> > hello. The same would happen with HTTP/1.1 if you tried to use
> > https with a server that only supports http.
>
> So that seems to be the issue.
> I had a look at your script - and I believe that if
> you had used HttpsServer.create() instead of HttpServer.create()
> you would have got the exception as expected.
>
> I am not sure there's much we can do there. If you try to send
> an HTTP/1.1 https:// request to that server youn will observe
> the same behavior.
>
> Specifically try this:
>
> ```
>      // http1 server on tcp 8080
>      // btw what if we made a conveniece method? I'll contribute it
> myself, just say the word
>      var http1 = HttpServer.create(new InetSocketAddress(8080), 0);
>      http1.createContext("/", ctx -> ctx.sendResponseHeaders(101, -1));
>      http1.start();
>
>      var client = HttpClient.newBuilder()
>         .version(HttpClient.Version.HTTP_1_1)
>         .build();
>      var request = HttpRequest.newBuilder()
>         .uri(URI.create("https://localhost:8080/"))
>         .build();
>      System.out.println("req: " + request);
>      var resp = client.send(request, HttpResponse.BodyHandlers.ofString());
>      System.out.println("resp: " + resp);
> ```
>
> This has the same behaviour and does not involve HTTP/3.
> To see the exception, add this to the request in your
> original script:
>
> ```
> import java.net.http.HttpOption;
> import static java.net.http.HttpOption.H3_DISCOVERY;
> import static java.net.http.HttpOption.Http3DiscoveryMode.HTTP_3_URI_ONLY;
>
> ...
>
>       HttpRequest.newBuilder().uri(URI.create("https://localhost:8080"))
>          .setOption(H3_DISCOVERY, HTTP_3_URI_ONLY)   <<<<< HTTP/3 only
>          .GET().build(),
> ```
>
> this will prevent the client from falling back to TCP.
>
> best regards,
>
> -- daniel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251107/07ba50b1/attachment-0001.htm>

From djelinski at openjdk.org  Fri Nov  7 14:01:24 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Nov 2025 14:01:24 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
Message-ID: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>

> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.

This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.

CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.

A new test was added to exercise the new congestion controller. Existing tests continue to pass.

-------------

Depends on: https://git.openjdk.org/jdk/pull/28156

Commit messages:
 - Add a system property to select congestion controller
 - Implement fast convergence
 - Add comments
 - Update test
 - Revert: more aggressive window increases
 - Test the cubic curve
 - Use custom timeline for testing
 - Documentation updates
 - Cubic tests, more aggressive Reno window increase
 - Log K in milliseconds
 - ... and 2 more: https://git.openjdk.org/jdk/compare/dab80e58...b95950f2

Changes: https://git.openjdk.org/jdk/pull/28195/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371475
  Stats: 974 lines in 5 files changed: 715 ins; 252 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28195/head:pull/28195

PR: https://git.openjdk.org/jdk/pull/28195

From alanb at openjdk.org  Fri Nov  7 14:12:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 7 Nov 2025 14:12:00 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <T8NWGoyhliJjZV2cHbgTKuJznwy7rPW4fjmqh-W4I_U=.042e01b3-9f30-45d3-922a-1abb5372ffad@github.com>

On Fri, 7 Nov 2025 13:38:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

If jdk.httpclient.quic.congestionController is exposed then we'll need to track this with a CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28195#issuecomment-3502776805

From dfuchs at openjdk.org  Fri Nov  7 14:26:20 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 14:26:20 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled
Message-ID: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>

Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.

-------------

Commit messages:
 - 8371471: HttpClient: Log HTTP/3 handshake failures if logging errors is enabled

Changes: https://git.openjdk.org/jdk/pull/28196/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371471
  Stats: 185 lines in 3 files changed: 183 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28196/head:pull/28196

PR: https://git.openjdk.org/jdk/pull/28196

From michaelm at openjdk.org  Fri Nov  7 14:34:50 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 7 Nov 2025 14:34:50 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  updated remaining callsites for new constants

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28132/files
  - new: https://git.openjdk.org/jdk/pull/28132/files/5633b0de..15f4179f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=04-05

  Stats: 97 lines in 39 files changed: 40 ins; 0 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From vyazici at openjdk.org  Fri Nov  7 14:46:53 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 14:46:53 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v12]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <ZnJ5fXjozyDCp9T_H90SJ_HaP630ZVbE4V02rUZQ4b0=.8436c7de-b638-44e0-a9e2-3ec452c7bd6f@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Cancel timer right away if response body is not permitted

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/c3210d88..4b4a8e6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=10-11

  Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Fri Nov  7 14:46:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 14:46:54 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v11]
In-Reply-To: <Pl7BWOqK_lDFWbMrJs44yBBRN8U9AaGQkq_Q5TbBz5A=.ba033cae-c629-4052-ae66-d248c72b4723@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <LRmk6VTU3tyNUpz-c0aE0PMcY5XZxIBqywiI2L2XR-k=.de32039d-a5d7-4304-9e25-c4daf9886097@github.com>
 <8gEPtGRUveHAPt1A3gCD3wV1_9abcIV0Zjsm6_bRMos=.f90f431e-85f7-45ab-b9af-acb7f9bd2f53@github.com>
 <-ixnshakO8f7lzts65WM2LXcjmFYGxMknHYZsEMlGPk=.ca4d034b-99de-42cd-9082-fcf326446fe1@github.com>
 <Pl7BWOqK_lDFWbMrJs44yBBRN8U9AaGQkq_Q5TbBz5A=.ba033cae-c629-4052-ae66-d248c72b4723@github.com>
Message-ID: <rUtpQSn3iBoyogPTaYAIiQp3b6zseQrq15b4D3XDSG8=.52707f5b-143a-4fcb-8db1-02ec2e7a3623@github.com>

On Fri, 7 Nov 2025 09:52:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> after line 405 below
>> 
>> @dfuch, do you mean right after the `if (bodyNotPermitted(r)) {` line? (Sorry, I find line numbers difficult to track in the flux of changes.)
>
> if (bodyNotPermitted(r)) {
>                             if (bodyIsPresent(r)) {
> 
> between these two lines :-)

Implemented in 4b4a8e6ea64.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2503913741

From dfuchs at openjdk.org  Fri Nov  7 14:51:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 14:51:32 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
Message-ID: <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>

> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.

Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:

 - More copyright dates
 - small test cleanup
 - Fix copyright dates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28196/files
  - new: https://git.openjdk.org/jdk/pull/28196/files/f125305e..238904e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=00-01

  Stats: 18 lines in 2 files changed: 9 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28196/head:pull/28196

PR: https://git.openjdk.org/jdk/pull/28196

From jpai at openjdk.org  Fri Nov  7 15:03:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Nov 2025 15:03:15 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
Message-ID: <5JjgBOENelTIfp2wcbLyQAXAg53k8sJcY3MQYm7e0DI=.9aca261c-aa06-44f4-a7be-314eb2c6aded@github.com>

On Fri, 7 Nov 2025 14:51:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More copyright dates
>  - small test cleanup
>  - Fix copyright dates

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 596:

> 594:                 if (Log.errors()) {
> 595:                     Log.logError("%s QUIC handshake failed: %s"
> 596:                             .formatted(logTag(), message(cause)));

I think we don't need the new `message(...)` method here. Perhaps just doing:

Log.logError("%s QUIC handshake failed: %s".formatted(logTag(), cause));

is enough? For example, in jshell I see the following:


jshell> Throwable x = new Throwable()
jshell> Throwable y = new Throwable("foo bar")

jshell> "%s QUIC handshake failed: %s".formatted("tag", x)
$5 ==> "tag QUIC handshake failed: java.lang.Throwable"

jshell> "%s QUIC handshake failed: %s".formatted("tag", y)
$6 ==> "tag QUIC handshake failed: java.lang.Throwable: foo bar"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504018297

From jpai at openjdk.org  Fri Nov  7 15:07:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Nov 2025 15:07:13 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
Message-ID: <mcPt1PRM7bmybny-qQQdJHc0kNoAdL8Gh5FF1lNzM7g=.196f6126-13c2-4c5c-86df-1ca98c4f0e3b@github.com>

On Fri, 7 Nov 2025 14:51:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More copyright dates
>  - small test cleanup
>  - Fix copyright dates

test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 132:

> 130:             @Override
> 131:             public void publish(LogRecord record) {
> 132:                 record.getSourceClassName();

Is this line a leftover? Or does it intentionally call this method and not use the return value?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504037578

From dfuchs at openjdk.org  Fri Nov  7 15:13:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 15:13:16 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <5JjgBOENelTIfp2wcbLyQAXAg53k8sJcY3MQYm7e0DI=.9aca261c-aa06-44f4-a7be-314eb2c6aded@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
 <5JjgBOENelTIfp2wcbLyQAXAg53k8sJcY3MQYm7e0DI=.9aca261c-aa06-44f4-a7be-314eb2c6aded@github.com>
Message-ID: <nes_3YOFsYjH4tK2nGiSHo8bzg-DtOBb21LgUcGog8w=.773d3395-0b3c-4b51-adba-f54d256ce04e@github.com>

On Fri, 7 Nov 2025 15:00:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - More copyright dates
>>  - small test cleanup
>>  - Fix copyright dates
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 596:
> 
>> 594:                 if (Log.errors()) {
>> 595:                     Log.logError("%s QUIC handshake failed: %s"
>> 596:                             .formatted(logTag(), message(cause)));
> 
> I think we don't need the new `message(...)` method here. Perhaps just doing:
> 
> Log.logError("%s QUIC handshake failed: %s".formatted(logTag(), cause));
> 
> is enough? For example, in jshell I see the following:
> 
> 
> jshell> Throwable x = new Throwable()
> jshell> Throwable y = new Throwable("foo bar")
> 
> jshell> "%s QUIC handshake failed: %s".formatted("tag", x)
> $5 ==> "tag QUIC handshake failed: java.lang.Throwable"
> 
> jshell> "%s QUIC handshake failed: %s".formatted("tag", y)
> $6 ==> "tag QUIC handshake failed: java.lang.Throwable: foo bar"

Right - the reason I did that originally is that I thought we might get a non-exported exception here. But I see that the terminator already translate the QuicTransportException before completing the handshake.

> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 132:
> 
>> 130:             @Override
>> 131:             public void publish(LogRecord record) {
>> 132:                 record.getSourceClassName();
> 
> Is this line a leftover? Or does it intentionally call this method and not use the return value?

It does intentionally call it to force the LogRecord to infer the caller at the right place. Inferring the caller has to happen in the handler to ensure the right caller will be found.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504048630
PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504055194

From jpai at openjdk.org  Fri Nov  7 15:13:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Nov 2025 15:13:20 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
Message-ID: <RSA4Xj1kEYS6wobmQfYJJ0vukP_gigkhh-rCrPqzCgw=.92c93612-e54a-49be-92bd-517d17ffcf10@github.com>

On Fri, 7 Nov 2025 14:51:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More copyright dates
>  - small test cleanup
>  - Fix copyright dates

test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 119:

> 117: 
> 118:         // create a client that doesn't have the server's
> 119:         // certificate

Should we reword this to:


// create a client without the test specific SSLContext 
// so that the client doesn't have the server's
// certificate

test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 126:

> 124:         final HttpRequest.Builder reqBuilder = HttpRequest.newBuilder(reqURI)
> 125:                 .version(HTTP_3);
> 126:         Logger serverLogger = Logger.getLogger("jdk.httpclient.HttpClient");

Should we add a reachability fence for this `serverLogger`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504058024
PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504065336

From dfuchs at openjdk.org  Fri Nov  7 15:18:19 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 15:18:19 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <RSA4Xj1kEYS6wobmQfYJJ0vukP_gigkhh-rCrPqzCgw=.92c93612-e54a-49be-92bd-517d17ffcf10@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
 <RSA4Xj1kEYS6wobmQfYJJ0vukP_gigkhh-rCrPqzCgw=.92c93612-e54a-49be-92bd-517d17ffcf10@github.com>
Message-ID: <NSKGFdoP9YD3kEIc_ua7YB5GvJAyx6NnYQAxNNcLpps=.35d48b62-e49a-4630-8f16-120d090dff9b@github.com>

On Fri, 7 Nov 2025 15:10:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - More copyright dates
>>  - small test cleanup
>>  - Fix copyright dates
>
> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 126:
> 
>> 124:         final HttpRequest.Builder reqBuilder = HttpRequest.newBuilder(reqURI)
>> 125:                 .version(HTTP_3);
>> 126:         Logger serverLogger = Logger.getLogger("jdk.httpclient.HttpClient");
> 
> Should we add a reachability fence for this `serverLogger`?

Good point. When I started coding I thought it would be used in the finally block but in the end I forgot about it.

> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 153:
> 
>> 151:             // place where we log the exception from changes.
>> 152:             String expectedClassName = QuicConnectionImpl.class.getName()
>> 153:                     + "$HandshakeFlow";
> 
> Would just asserting for the (expected) log message and the presence of stacktrace be enough? Irrespective of which class logs it?

Possibly. Let's keep that for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504081188
PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504088339

From jpai at openjdk.org  Fri Nov  7 15:18:20 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Nov 2025 15:18:20 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
Message-ID: <c7AO1ydcbzcU5xntCyUG-JzBIiIyfbILeTDj5Tg7Xts=.c8f460a0-87ff-4a08-8686-4d89286e64fb@github.com>

On Fri, 7 Nov 2025 14:51:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - More copyright dates
>  - small test cleanup
>  - Fix copyright dates

test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 153:

> 151:             // place where we log the exception from changes.
> 152:             String expectedClassName = QuicConnectionImpl.class.getName()
> 153:                     + "$HandshakeFlow";

Would just asserting for the (expected) log message and the presence of stacktrace be enough? Irrespective of which class logs it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504078683

From dfuchs at openjdk.org  Fri Nov  7 15:30:20 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 15:30:20 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v3]
In-Reply-To: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
Message-ID: <joZtrdxNXWme7fLjL3JK4qZofJypbYqr8qSvkTJQalw=.427740f7-0fdd-4bd1-b60d-c32f693c5f0a@github.com>

> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28196/files
  - new: https://git.openjdk.org/jdk/pull/28196/files/238904e4..ff71b9e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=01-02

  Stats: 16 lines in 2 files changed: 6 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28196/head:pull/28196

PR: https://git.openjdk.org/jdk/pull/28196

From dfuchs at openjdk.org  Fri Nov  7 15:30:24 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 15:30:24 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <nes_3YOFsYjH4tK2nGiSHo8bzg-DtOBb21LgUcGog8w=.773d3395-0b3c-4b51-adba-f54d256ce04e@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
 <5JjgBOENelTIfp2wcbLyQAXAg53k8sJcY3MQYm7e0DI=.9aca261c-aa06-44f4-a7be-314eb2c6aded@github.com>
 <nes_3YOFsYjH4tK2nGiSHo8bzg-DtOBb21LgUcGog8w=.773d3395-0b3c-4b51-adba-f54d256ce04e@github.com>
Message-ID: <-wgQ5SGSnmA9qDuMpL_Lm5Rp_4NhS-l6OEhJETR1pr4=.bdf85618-8665-4d7d-b885-2dab385830db@github.com>

On Fri, 7 Nov 2025 15:07:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 596:
>> 
>>> 594:                 if (Log.errors()) {
>>> 595:                     Log.logError("%s QUIC handshake failed: %s"
>>> 596:                             .formatted(logTag(), message(cause)));
>> 
>> I think we don't need the new `message(...)` method here. Perhaps just doing:
>> 
>> Log.logError("%s QUIC handshake failed: %s".formatted(logTag(), cause));
>> 
>> is enough? For example, in jshell I see the following:
>> 
>> 
>> jshell> Throwable x = new Throwable()
>> jshell> Throwable y = new Throwable("foo bar")
>> 
>> jshell> "%s QUIC handshake failed: %s".formatted("tag", x)
>> $5 ==> "tag QUIC handshake failed: java.lang.Throwable"
>> 
>> jshell> "%s QUIC handshake failed: %s".formatted("tag", y)
>> $6 ==> "tag QUIC handshake failed: java.lang.Throwable: foo bar"
>
> Right - the reason I did that originally is that I thought we might get a non-exported exception here. But I see that the terminator already translate the QuicTransportException before completing the handshake.

Done

>> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 126:
>> 
>>> 124:         final HttpRequest.Builder reqBuilder = HttpRequest.newBuilder(reqURI)
>>> 125:                 .version(HTTP_3);
>>> 126:         Logger serverLogger = Logger.getLogger("jdk.httpclient.HttpClient");
>> 
>> Should we add a reachability fence for this `serverLogger`?
>
> Good point. When I started coding I thought it would be used in the finally block but in the end I forgot about it.

I stuck it in a static field and renamed it to clientLogger.

>> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 132:
>> 
>>> 130:             @Override
>>> 131:             public void publish(LogRecord record) {
>>> 132:                 record.getSourceClassName();
>> 
>> Is this line a leftover? Or does it intentionally call this method and not use the return value?
>
> It does intentionally call it to force the LogRecord to infer the caller at the right place. Inferring the caller has to happen in the handler to ensure the right caller will be found.

added a comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504141697
PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504137443
PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504140582

From dfuchs at openjdk.org  Fri Nov  7 15:30:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 15:30:26 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v2]
In-Reply-To: <RSA4Xj1kEYS6wobmQfYJJ0vukP_gigkhh-rCrPqzCgw=.92c93612-e54a-49be-92bd-517d17ffcf10@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <FqT_8e_taYONkiiTWqBDz93I1nlFuaz2bioT3WZLWmU=.ca0debe9-01eb-46c8-86f7-d6b48bb4462e@github.com>
 <RSA4Xj1kEYS6wobmQfYJJ0vukP_gigkhh-rCrPqzCgw=.92c93612-e54a-49be-92bd-517d17ffcf10@github.com>
Message-ID: <9swS1TpDm15FU8zJFisrtcNj8akNYIsWsjTZmODWvrY=.5a12f7a6-9c2d-4fc6-ab7d-31d6bd29d53c@github.com>

On Fri, 7 Nov 2025 15:09:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - More copyright dates
>>  - small test cleanup
>>  - Fix copyright dates
>
> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 119:
> 
>> 117: 
>> 118:         // create a client that doesn't have the server's
>> 119:         // certificate
> 
> Should we reword this to:
> 
> 
> // create a client without the test specific SSLContext 
> // so that the client doesn't have the server's
> // certificate

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504139112

From jpai at openjdk.org  Fri Nov  7 16:48:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Nov 2025 16:48:01 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v3]
In-Reply-To: <joZtrdxNXWme7fLjL3JK4qZofJypbYqr8qSvkTJQalw=.427740f7-0fdd-4bd1-b60d-c32f693c5f0a@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <joZtrdxNXWme7fLjL3JK4qZofJypbYqr8qSvkTJQalw=.427740f7-0fdd-4bd1-b60d-c32f693c5f0a@github.com>
Message-ID: <vUzg4s4gO2dhtUZyI-hM4bp2MIY8J7IM8Y53RjM4-j8=.b0eea625-cc53-4848-be8f-a9e8845f26c1@github.com>

On Fri, 7 Nov 2025 15:30:20 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 151:

> 149:             System.out.println("Issuing request: " + req1);
> 150:             final HttpResponse<Void> resp1 = client.send(req1, BodyHandlers.discarding());
> 151:             Assert.assertEquals(resp1.statusCode(), 200, "unexpected response code for GET request");

Sorry I missed htis in the previous round of review. Shouldn't this line be a `fail("Request expected to fail but didn't")`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504537116

From dfuchs at openjdk.org  Fri Nov  7 16:54:02 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 16:54:02 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
Message-ID: <A91poRxPfb8tDqhHrsiGX3Ovo0ySU_Oj6uadcu8B-Qo=.868a7e31-79bf-4a1d-8cb2-c7adcc67be7c@github.com>

On Fri, 7 Nov 2025 14:34:50 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated remaining callsites for new constants

LGTM. Please hold off integrating right now -  I've launched a couple of tests.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28132#pullrequestreview-3435173192

From dfuchs at openjdk.org  Fri Nov  7 17:05:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 17:05:03 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v3]
In-Reply-To: <vUzg4s4gO2dhtUZyI-hM4bp2MIY8J7IM8Y53RjM4-j8=.b0eea625-cc53-4848-be8f-a9e8845f26c1@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <joZtrdxNXWme7fLjL3JK4qZofJypbYqr8qSvkTJQalw=.427740f7-0fdd-4bd1-b60d-c32f693c5f0a@github.com>
 <vUzg4s4gO2dhtUZyI-hM4bp2MIY8J7IM8Y53RjM4-j8=.b0eea625-cc53-4848-be8f-a9e8845f26c1@github.com>
Message-ID: <NND4YqP8AQi3XUM8tVhZI5cI-enjMBtMa2r6mj14cWw=.4455dc44-754d-439e-bae5-7104a9accc05@github.com>

On Fri, 7 Nov 2025 16:45:01 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 151:
> 
>> 149:             System.out.println("Issuing request: " + req1);
>> 150:             final HttpResponse<Void> resp1 = client.send(req1, BodyHandlers.discarding());
>> 151:             Assert.assertEquals(resp1.statusCode(), 200, "unexpected response code for GET request");
> 
> Sorry I missed htis in the previous round of review. Shouldn't this line be a `fail("Request expected to fail but didn't")`?

Oh sorry I meant to just remove this line. I thought it was better to not configure HTTP_3_URI_ONLY on the request in order to trigger the fallback on TCP. So something might actually respond. If something responds then we could get a response. On the other hand this might impacts other tests that might run on the machine...
hmmm... maybe I should fix that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504607829

From vyazici at openjdk.org  Fri Nov  7 17:30:12 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 17:30:12 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <PO3Qf37aLMxE5wZva5VgmXgefcDg5Yo2Mc8eumoXOLM=.d89bd085-95a7-4b89-b0b1-d9543d4ad2d7@github.com>

On Fri, 7 Nov 2025 13:38:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

Really neat work @djelinski! I liked the surgery you carried out in `QuicBaseCC`. ?

I've dropped some minor remarks. I guess we will need some time to wrap our mind around the math involved in the PR.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 371:

> 369:     private static QuicCongestionController createCongestionController
> 370:             (String dbgTag, QuicRttEstimator rttEstimator) {
> 371:         String algo = System.getProperty("jdk.httpclient.quic.congestionController", "cubic");

Can we keep this internal? That is, can we use `jdk.internal.httpclient.quic.congestionController` instead?

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 41:

> 39:  *       RFC 9438: CUBIC for Fast and Long-Distance Networks
> 40:  */
> 41: public class QuicCubicCongestionController extends QuicBaseCongestionController {

I guess this can be `final`.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 62:

> 60:     public QuicCubicCongestionController(String dbgTag, QuicRttEstimator rttEstimator) {
> 61:         super(dbgTag, rttEstimator);
> 62:         this.rttEstimator = rttEstimator;

Can we make `rttEstimator` a `protected` field of `QuicBaseCongestionController`?

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 112:

> 110:     protected boolean congestionAvoidanceAcked(int packetBytes, Deadline sentTime) {
> 111:         boolean isAppLimited;
> 112:         isAppLimited = sentTime.isAfter(lastFullWindow);

Suggestion:

        boolean isAppLimited = sentTime.isAfter(lastFullWindow);

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 122:

> 120:             // target = Wcubic(t)
> 121:             // this is less aggressive than RFC 9438, which uses target=Wcubic(t+RTT),
> 122:             // but seems to work well enough

Shall we also document why we deviate from the RFC?

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicRenoCongestionController.java line 40:

> 38:  *      RFC 9002: QUIC Loss Detection and Congestion Control
> 39:  */
> 40: class QuicRenoCongestionController extends QuicBaseCongestionController {

I guess thins can be `final` and consequently `protected` modifier can be removed from the implemented methods.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicRenoCongestionController.java line 47:

> 45:     protected boolean congestionAvoidanceAcked(int packetBytes, Deadline sentTime) {
> 46:         boolean isAppLimited;
> 47:         isAppLimited = congestionWindow > maxBytesInFlight + 2L * maxDatagramSize;

Suggestion:

        boolean isAppLimited = congestionWindow > maxBytesInFlight + 2L * maxDatagramSize;


@djelinski, I see you verbatim copied these lines ? which is fine, and makes things easier to review. Nevertheless, I want to double-check: do we need to guard against any arithmetic overflows here?

test/jdk/java/net/httpclient/quic/CubicTest.java line 42:

> 40: /*
> 41:  * @test
> 42:  * @run testng/othervm -Djdk.httpclient.HttpClient.log=trace,quic:cc CubicTest

Shall we use JUnit instead?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28195#pullrequestreview-3435245896
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504693701
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504645030
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504653829
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504673398
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504672752
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504622773
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504632463
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2504680316

From vyazici at openjdk.org  Fri Nov  7 17:39:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 7 Nov 2025 17:39:03 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <x3iPVP-ivFelAZSVLEl5iaVwhySIFu6j28sQ3EoWrUM=.5151904d-c721-485d-b0ad-a19d32b2721b@github.com>

On Thu, 6 Nov 2025 16:22:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

@dfuch, could replacing `1ms` sleeps in `RawChannelTest` with `1ns` be a solution too?

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28178#pullrequestreview-3435397100

From dfuchs at openjdk.org  Fri Nov  7 17:40:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 17:40:22 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v4]
In-Reply-To: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
Message-ID: <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>

> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback - request should fail

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28196/files
  - new: https://git.openjdk.org/jdk/pull/28196/files/ff71b9e1..b99dd15f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28196&range=02-03

  Stats: 43 lines in 1 file changed: 41 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28196.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28196/head:pull/28196

PR: https://git.openjdk.org/jdk/pull/28196

From dfuchs at openjdk.org  Fri Nov  7 17:42:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 17:42:11 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <6GESBgxXyGMM-Z4JULHL9j3A9GyCWyyk8hHC1nujUh4=.cae22bbc-cdd3-4c09-a077-cf6c98232a66@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
 <6GESBgxXyGMM-Z4JULHL9j3A9GyCWyyk8hHC1nujUh4=.cae22bbc-cdd3-4c09-a077-cf6c98232a66@github.com>
Message-ID: <BeTYyonKtNim-uN_kl9P_gnFC6UtKKVHYLdr9ePkVAI=.6bd8726f-2ad6-4ec3-803e-5cdd36e60e60@github.com>

On Thu, 6 Nov 2025 18:05:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
>> 
>> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.
>
> Yes.

> @dfuch, could replacing `1ms` sleeps in `RawChannelTest` with `1ns` be a solution too?

No idea. I'm not sure whether it would work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3503864889

From dfuchs at openjdk.org  Fri Nov  7 18:01:02 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 7 Nov 2025 18:01:02 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v3]
In-Reply-To: <NND4YqP8AQi3XUM8tVhZI5cI-enjMBtMa2r6mj14cWw=.4455dc44-754d-439e-bae5-7104a9accc05@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <joZtrdxNXWme7fLjL3JK4qZofJypbYqr8qSvkTJQalw=.427740f7-0fdd-4bd1-b60d-c32f693c5f0a@github.com>
 <vUzg4s4gO2dhtUZyI-hM4bp2MIY8J7IM8Y53RjM4-j8=.b0eea625-cc53-4848-be8f-a9e8845f26c1@github.com>
 <NND4YqP8AQi3XUM8tVhZI5cI-enjMBtMa2r6mj14cWw=.4455dc44-754d-439e-bae5-7104a9accc05@github.com>
Message-ID: <72Hqdp_vQ05Rjm7OADtB29pfqdcm-tVf7bOfNYCtcH8=.4949b35f-c582-49fd-9e22-c0f6393c00c7@github.com>

On Fri, 7 Nov 2025 17:01:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http3/H3LogHandshakeErrors.java line 151:
>> 
>>> 149:             System.out.println("Issuing request: " + req1);
>>> 150:             final HttpResponse<Void> resp1 = client.send(req1, BodyHandlers.discarding());
>>> 151:             Assert.assertEquals(resp1.statusCode(), 200, "unexpected response code for GET request");
>> 
>> Sorry I missed htis in the previous round of review. Shouldn't this line be a `fail("Request expected to fail but didn't")`?
>
> Oh sorry I meant to just remove this line. I thought it was better to not configure HTTP_3_URI_ONLY on the request in order to trigger the fallback on TCP. So something might actually respond. If something responds then we could get a response. On the other hand this might impacts other tests that might run on the machine...
> hmmm... maybe I should fix that.

The test now creates a TCP ServerSocket bound to the same port and which will close accepted connections. That should ensure safe fallback on TCP. If the ServerSocket cannot be created (address already in use) then the request will be configured with HTTP3_URI_ONLY to prevent fallback to TCP.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504827168

From msheppar at openjdk.org  Fri Nov  7 18:17:03 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Fri, 7 Nov 2025 18:17:03 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <E_pI4okmg4Nd_mSOsL197YCHJ84WSmO1zmgJvihA6Ig=.d3b6e2b4-bd48-46de-85ee-9521fe9d502b@github.com>

On Thu, 6 Nov 2025 16:22:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

It is fine to increase the jtreg test timeout. BUT with the TIMEOUT FACTOR reverted to 4 and hence  an overall jtreg timeout 8 minutes, the most likely outcome of increasing the test's explicit timeout to 240 is, when this "moribund" condition arises, for the test to timeout after 16 minutes.

The process capture suggests that the writer and reader in the readSlowly and writeSlowly have got stuck  
It's a complex enough test with the HttpClient also stuck in a "poll" waiting on network events
I haven't study the test in depth, but it smells like a race condition/conditions

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3504071234

From djelinski at openjdk.org  Fri Nov  7 18:29:02 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 7 Nov 2025 18:29:02 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v4]
In-Reply-To: <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
Message-ID: <x53cXKnIolriXlGoSKHHtxqmXfC0jrwoF3sq0duB2gI=.f18c7ae2-cda1-4a66-af4b-412b94d4462b@github.com>

On Fri, 7 Nov 2025 17:40:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback - request should fail

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 597:

> 595:                     Log.logError("%s QUIC handshake failed: %s"
> 596:                             .formatted(logTag(), cause));
> 597:                     Log.logError(cause);

This produces 2 error messages like:

Nov 07, 2025 6:01:57 PM jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow failHandshakeCFs
INFO: ERROR: QuicServerConnection(1) QUIC handshake failed: java.io.IOException: Connection closed by client peer: CRYPTO_ERROR|certificate_unknown certificate_unknown
Nov 07, 2025 6:01:57 PM jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow failHandshakeCFs
INFO: ERROR: java.io.IOException: Connection closed by client peer: CRYPTO_ERROR|certificate_unknown certificate_unknown
java.io.IOException: Connection closed by client peer: CRYPTO_ERROR|certificate_unknown certificate_unknown
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:129)

Can we remove the duplicate information? Currently there are 2 timestamps, and the exception message is printed 3 times.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2504917595

From djelinski at openjdk.org  Sat Nov  8 08:59:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 8 Nov 2025 08:59:01 GMT
Subject: RFR: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread [v4]
In-Reply-To: <eeJdtLMXD4ek0ex3wC19FXuT1AZsoV-GtqJvAnz57UQ=.d0e1ccc1-a305-41cf-bc32-3af396ec5ea7@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
 <eeJdtLMXD4ek0ex3wC19FXuT1AZsoV-GtqJvAnz57UQ=.d0e1ccc1-a305-41cf-bc32-3af396ec5ea7@github.com>
Message-ID: <rbJSZudOuL7HtGpIm7b53SyThPfn07BM_VAHEnK8Ygg=.59163812-72a3-4116-a254-4fc4c5a63574@github.com>

On Tue, 4 Nov 2025 15:16:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
>> 
>> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.
>
> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Apply suggestion from @vy
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Apply suggestion from @vy
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update the test to match the new property name

LGTM.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27827#pullrequestreview-3437875655

From dfuchs at openjdk.org  Sat Nov  8 12:46:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Sat, 8 Nov 2025 12:46:01 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v4]
In-Reply-To: <x53cXKnIolriXlGoSKHHtxqmXfC0jrwoF3sq0duB2gI=.f18c7ae2-cda1-4a66-af4b-412b94d4462b@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
 <x53cXKnIolriXlGoSKHHtxqmXfC0jrwoF3sq0duB2gI=.f18c7ae2-cda1-4a66-af4b-412b94d4462b@github.com>
Message-ID: <yTQXFViubWXZ8xzbYJT7g139GjIYup6NNL6LBrz3Giw=.b1033e9b-0292-4f30-a726-75f21bcda0d1@github.com>

On Fri, 7 Nov 2025 18:26:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback - request should fail
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 597:
> 
>> 595:                     Log.logError("%s QUIC handshake failed: %s"
>> 596:                             .formatted(logTag(), cause));
>> 597:                     Log.logError(cause);
> 
> This produces 2 error messages like:
> 
> Nov 07, 2025 6:01:57 PM jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow failHandshakeCFs
> INFO: ERROR: QuicServerConnection(1) QUIC handshake failed: java.io.IOException: Connection closed by client peer: CRYPTO_ERROR|certificate_unknown certificate_unknown
> Nov 07, 2025 6:01:57 PM jdk.internal.net.http.quic.QuicConnectionImpl$HandshakeFlow failHandshakeCFs
> INFO: ERROR: java.io.IOException: Connection closed by client peer: CRYPTO_ERROR|certificate_unknown certificate_unknown
> java.io.IOException: Connection closed by client peer: CRYPTO_ERROR|certificate_unknown certificate_unknown
> 	at java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:129)
> 
> Can we remove the duplicate information? Currently there are 2 timestamps, and the exception message is printed 3 times.

I have considered this. This would require adding a new `logError` metod to `Log`:

    public void logError(String msg, Throwable throwable) {
         ....
    } 

I refrained from doing that because there may be place where we call logError with a message and a throwable and don't expect to see the stack trace. That would require examining all such call sites and cast the `Throwable` to `Object` - or add a call to toString() - so that they keep on calling `logError(String, Object...)`.

I'd rather do that in a separate cleanup.

FWIW - what you are seeing in the quoted log are a mix of client traces and server traces: the message on the server talks of the `client peer`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2506894610

From ehs122100 at gmail.com  Sat Nov  8 13:08:59 2025
From: ehs122100 at gmail.com (Hyunsu Eun)
Date: Sat, 8 Nov 2025 22:08:59 +0900
Subject: 8328894: HttpResponse.body() returns null with https target and
 failed proxy authentication
Message-ID: <E4B9618A-1427-44EF-97E4-721AAD8B147A@gmail.com>

Hi,

I noticed JDK-8328894 [1] has been open since March 2024 and would like
to help if possible.

I've analyzed the issue and created a potential fix that preserves the proxy
response body for 407 authentication errors in HTTPS tunneling. 

The fix:
- Changes CONNECT exchange from MultiExchange<Void> to MultiExchange<byte[]>
- Caches the proxy response body and returns it through Exchange.readBodyAsync()
- Adds a test case (ProxyAuthHttpsTest.java) to verify the behavior

The root cause is that HTTPS uses CONNECT tunneling with a Void body type,
and the 407 response body was being discarded via ignoreBody() instead of
being preserved for the application.

I've tested this locally and confirmed it addresses the issue:
- Before: https:// with 407 returns null body
- After: https:// with 407 returns body correctly (matching http:// behavior)

I'd be happy to submit a PR or share more details about the approach if helpful.

Thanks,
Hyunsu Eun

[1] https://bugs.openjdk.org/browse/JDK-8328894

From duke at openjdk.org  Sat Nov  8 15:54:05 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 8 Nov 2025 15:54:05 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved
In-Reply-To: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
Message-ID: <VSslpKqIK0pOIzDt4JxUMzVdkT24C_IpkMfC1AlZbyE=.0f9eb358-aed5-4ff7-98d0-93d4eb8f169e@github.com>

On Mon, 15 Sep 2025 02:50:27 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.

bump

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3506660404

From josiahnoel at gmail.com  Sat Nov  8 16:23:49 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Sat, 8 Nov 2025 11:23:49 -0500
Subject: Http 3 Client request timeout not respected
Message-ID: <CAJ_t5UZzWsGUmnt9Q5D1c26HM-8OpCptvt4OS92vw-VisxU9sA@mail.gmail.com>

Long time no see,

I was trying a long running request with the new client and it seems that
after 30 seconds it cuts the request, regardless of whether I specify a
longer request timeout. Is there a different mechanism for configuration?

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251108/044442c0/attachment-0001.htm>
-------------- next part --------------
WARNING: Unknown module: io.avaje.jex.test specified to --add-reads
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.Http3ClientImpl getConnectionFor
INFO: HTTP3: getConnectionFor exchange https://localhost:8080 GET #1
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.Http3ClientImpl getConnectionFor
INFO: HTTP3: Creating connection for Exchange https://localhost:8080 GET #1
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.HttpQuicConnection logAltSvcFor
INFO: ALTSVC: No AltService found for localhost:8080
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.quic.QuicClient chooseEndpoint
INFO: QUIC: Adding new endpoint: QuicEndpoint(HttpClientImpl(1)-0)
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.quic.QuicEndpoint lambda$create$1
INFO: QUIC: Initial receive buffer size is: 65536
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.quic.QuicEndpoint lambda$create$1
INFO: QUIC: Initial send buffer size is: 65536
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.Http3Connection createAsync
INFO: HTTP3: Http3Connection.createAsync: Got HttpQuicConnection for https://localhost:8080 GET #1 is: quic:1
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.quic.QuicConnectionImpl startInitialTimer
INFO: QUIC: QuicClientConnection(1): Arming quic initial timer for PT29.9996546S
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.quic.QuicConnectionImpl sendFirstInitialPacket
INFO: QUIC: QuicClientConnection(1): connectionId: 230ecedb5372809bf43d4c08a9e96186db369c, QuicEndpoint(HttpClientImpl(1)-0): QuicEndpoint(HttpClientImpl(1)-0) - /[0:0:0:0:0:0:0:0]:59552
Nov 08, 2025 11:15:40 AM jdk.internal.net.http.quic.IdleTimeoutManager checkUpdateIdleTimeout
INFO: QUIC: QuicClientConnection(1) idle connection timeout updated to 30,000 milli seconds
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): INITIAL no deadline, task unscheduled
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space INITIAL
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.IdleTimeoutManager startIdleTerminationTimer
INFO: QUIC: QuicClientConnection(1) started QUIC idle timeout management for connection, idle timeout event: QuicIdleTimeoutEvent-4 deadline: Deadline(2025-11-08T16:16:11.089526200Z)
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.IdleTimeoutManager startStreamDataBlockedTimer
INFO: QUIC: QuicClientConnection(1) started STREAM_DATA_BLOCKED timer for connection, event: StreamDataBlockedEvent-5 deadline: Deadline(2025-11-08T16:16:03.591024600Z)
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3Connection <init>
INFO: HTTP3: HTTP/3 connection created for QuicClientConnection(1) - local address: /[0:0:0:0:0:0:0:0]:59552
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:0, size=100, phase:-1, spin:-1, frames:[NewConnectionIDFrame(seqNumber=1, retirePriorTo=0, connIdLength=19), StreamFrame(stream=2, offset=0, length=1, fin=false), StreamFrame(stream=2, offset=1, length=27, fin=false)])
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl processDecrypted
INFO: QUIC: QuicClientConnection(1) IN: ONERTT(pn:0, size=43, phase:0, spin:0, frames:[HandshakeDoneFrame, StreamFrame(stream=3, offset=0, length=1, fin=false)])
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task unscheduled
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space HANDSHAKE
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.AltServicesRegistry registerUnadvertised
INFO: ALTSVC: Added unadvertised AltService: Optional[AltSvc: h3="localhost:8080"; origin="https://localhost:8080"; deadline=Deadline(2025-11-09T16:15:41.117233600Z); persist=true; advertised=false; sameAuthorityAsOrigin=true;]
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): HANDSHAKE no deadline, task unscheduled
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3ClientImpl connectionCompleted
INFO: HTTP3: Checking waiters on completed connection quic:1 to https:localhost:8080 created for https://localhost:8080 GET #1
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3ClientImpl connectionCompleted0
INFO: HTTP3: Connection creation completed for requests to https:localhost:8080: waiters[0](completed:0, retried:0, errors:0) - originally created for https://localhost:8080 GET #1
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): APPLICATION new deadline computed, deadline in 8ms
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl processDecrypted
INFO: QUIC: QuicClientConnection(1) IN: ONERTT(pn:2, size=110, phase:0, spin:0, frames:[NewConnectionIDFrame(seqNumber=1, retirePriorTo=0, connIdLength=8), CryptoFrame(offset=0, length=42)])
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3Connection createHttp3ExchangeImpl
INFO: HTTP3: Creating HTTP/3 exchange for QuicClientConnection(1)/streamId=0
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3ExchangeImpl start
INFO: HTTP3: Starting HTTP/3 exchange for QuicClientConnection(1)/streamId=0 (https://localhost:8080 GET #1)
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3ExchangeImpl sendHeaders
INFO: REQUEST: https://localhost:8080 GET
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.Http3ExchangeImpl sendHeaders
INFO: HEADERS: H3 HEADERS FRAME (stream=0)
    :authority: localhost:8080
    :method: GET
    :path: /
    :scheme: https
    User-Agent: Java-http-client/26-ea


Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:4, size=75, phase:-1, spin:-1, frames:[StreamFrame(stream=0, offset=0, length=2, fin=false), StreamFrame(stream=0, offset=2, length=2, fin=false), StreamFrame(stream=0, offset=4, length=34, fin=true)])
Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task unscheduled
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.IdleTimeoutManager idleTimedOut
INFO: QUIC: QuicClientConnection(1) silently terminating connection due to idle timeout (30000 milli seconds): 
  PacketSpace: INITIAL
    State: closed
    AckFrame: NextAckFrame[ackFrame=AckFrame(largestAcknowledged=0, ackDelay=0, ackRanges=[0..0]), deadline=Deadline(+1000000000-12-31T23:59:59.999999999Z), lastUpdated=Deadline(2025-11-08T16:15:41.062541500Z), sent=Deadline(2025-11-08T16:15:41.063069200Z)]
    Pending acks: ()
    Pending retransmit: ()
  PacketSpace: HANDSHAKE
    State: closed
    AckFrame: NextAckFrame[ackFrame=AckFrame(largestAcknowledged=2, ackDelay=0, ackRanges=[0..2]), deadline=Deadline(+1000000000-12-31T23:59:59.999999999Z), lastUpdated=Deadline(2025-11-08T16:15:41.088205900Z), sent=Deadline(2025-11-08T16:15:41.089417800Z)]
    Pending acks: ()
    Pending retransmit: ()
  PacketSpace: APPLICATION
    State: opened
    AckFrame: NextAckFrame[ackFrame=AckFrame(largestAcknowledged=4, ackDelay=0, ackRanges=[0..4]), deadline=Deadline(+1000000000-12-31T23:59:59.999999999Z), lastUpdated=Deadline(2025-11-08T16:15:41.178491500Z), sent=Deadline(2025-11-08T16:15:41.187927700Z)]
    Pending acks: ()
    Pending retransmit: ()
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.ConnectionTerminatorImpl silentTerminate
INFO: QUIC: QuicClientConnection(1) silently terminating connection due to: connection idle timed out (30000 milli seconds)
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.ConnectionTerminatorImpl silentTerminate
INFO: QUIC: QuicClientConnection(1) connection state: sending: {canSend:false, credit: 9999934, sendersReady: false, hasControlFrames: false}, cc: { backoff: 1, duration: PT0.152018S, current deadline: due since 30002ms, prospective deadline: not scheduled (Deadline.MAX)}, streams: [{id:0, available: 0, blocked: false},]
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space APPLICATION
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.Http3ExchangeImpl onPollException
INFO: HTTP3: QuicClientConnection(1)/streamId=0 https://localhost:8080 GET #1 (requestSent=true, responseReceived=false, reader=RECV, writer=DATA_RECVD, statusCode=0, finalStream=false, receivedQuicBytes=0, sentQuicBytes=38): java.io.IOException: connection idle timed out (30000 milli seconds)
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.Http3ExchangeImpl close
INFO: HTTP3: Closed HTTP/3 exchange for QuicClientConnection(1)/streamId=0 with error java.io.IOException: connection idle timed out (30000 milli seconds)
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.Http3Connection onExchangeClose
INFO: HTTP3: HTTP/3 connection QuicClientConnection(1) left open: exchanged streamId=0 closed; finalStream=false, exchangeStreams=0, reservedStreamCount=0
Exception in thread "main" java.io.IOException: connection idle timed out (30000 milli seconds)
	at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:1018)
	at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133)
	at io.avaje.jex.http3.flupke/io.avaje.jex.http3.flupke.Timeout.main(Timeout.java:86)
Caused by: java.io.IOException: connection idle timed out (30000 milli seconds)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:129)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.<init>(TerminationCause.java:56)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause$SilentTermination.<init>(TerminationCause.java:203)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.forSilentTermination(TerminationCause.java:96)
	at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager.idleTimedOut(IdleTimeoutManager.java:349)
	at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager$IdleTimeoutEvent.terminateNow(IdleTimeoutManager.java:437)
	at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager$IdleTimeoutEvent.handle(IdleTimeoutManager.java:411)
	at java.net.http/jdk.internal.net.http.quic.QuicTimerQueue.processDue(QuicTimerQueue.java:298)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	at java.base/java.lang.Thread.run(Thread.java:1474)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Timeout.java
Type: application/octet-stream
Size: 3252 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251108/044442c0/Timeout-0001.java>

From djelinski at openjdk.org  Sat Nov  8 20:24:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Sat, 8 Nov 2025 20:24:01 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v4]
In-Reply-To: <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
Message-ID: <-hcBnDkuvm6B_wcf48Jwdjj4DkHUlpxscvkbCQNOtI0=.2ac1d979-4401-45db-a1ed-21eaf7e7eb06@github.com>

On Fri, 7 Nov 2025 17:40:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback - request should fail

Doing this in a separate cleanup is fine by me. Note that one of the duplicates can be easily removed already.

src/java.net.http/share/classes/jdk/internal/net/http/common/Log.java line 394:

> 392:     public static void logError(Throwable t) {
> 393:         if (errors()) {
> 394:             logger.log(Level.INFO, "ERROR: " + t, t);

Suggestion:

            logger.log(Level.INFO, "ERROR:", t);

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28196#pullrequestreview-3438579143
PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2507114008

From michaelm at openjdk.org  Sat Nov  8 21:50:00 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Sat, 8 Nov 2025 21:50:00 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <A91poRxPfb8tDqhHrsiGX3Ovo0ySU_Oj6uadcu8B-Qo=.868a7e31-79bf-4a1d-8cb2-c7adcc67be7c@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
 <A91poRxPfb8tDqhHrsiGX3Ovo0ySU_Oj6uadcu8B-Qo=.868a7e31-79bf-4a1d-8cb2-c7adcc67be7c@github.com>
Message-ID: <IHZJGd6yJzyoS1F3D93ecv7ahxD_7r7u4TolerkDP7U=.f3ccb215-8dfe-4348-ab18-f9904065f134@github.com>

On Fri, 7 Nov 2025 16:51:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> LGTM. Please hold off integrating right now - I've launched a couple of tests.

My tier1 and tier2 test run passes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3506966971

From vyazici at openjdk.org  Mon Nov 10 09:06:52 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 10 Nov 2025 09:06:52 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v13]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <WhQrqzQ86TCqsXiKHdqUD-0y5A9F46RK2Su8_HAuYb4=.b740a69d-a3f9-4999-b82d-ed715efe5ba3@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge remote-tracking branch 'upstream/master' into respBodyTime
 - Cancel timer right away if response body is not permitted
 - Configure timeout for the `WebSocketTest`
 - Use `var`
 - Clarify WebSocket behaviour and test it
 - Verify no lingering response timers
 - Cancel timer on 204
 - Shorten `TimeoutResponseTestSupport` using imports
 - Make `MultiExchange::cancelTimer` package-private
 - Merge remote-tracking branch 'upstream/master' into respBodyTime
 - ... and 28 more: https://git.openjdk.org/jdk/compare/79fee607...802ce9de

-------------

Changes: https://git.openjdk.org/jdk/pull/27469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=12
  Stats: 1036 lines in 15 files changed: 1023 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From jaikiran.pai at oracle.com  Mon Nov 10 09:59:42 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Mon, 10 Nov 2025 15:29:42 +0530
Subject: Http 3 Client request timeout not respected
In-Reply-To: <CAJ_t5UZzWsGUmnt9Q5D1c26HM-8OpCptvt4OS92vw-VisxU9sA@mail.gmail.com>
References: <CAJ_t5UZzWsGUmnt9Q5D1c26HM-8OpCptvt4OS92vw-VisxU9sA@mail.gmail.com>
Message-ID: <37895ea9-3298-4843-8bf7-04986c0be342@oracle.com>

Hello Josiah,

Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl 
pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:4, size=75, phase:-1, 
spin:-1, frames:[StreamFrame(stream=0, offset=0, length=2, fin=false), 
StreamFrame(stream=0, offset=2, length=2, fin=false), 
StreamFrame(stream=0, offset=4, length=34, fin=true)])
...
INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task 
unscheduled
Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.IdleTimeoutManager 
idleTimedOut

The long running request, is it generating any response during those 30 
seconds from the server to the client or is it handling the request on 
the server side without generating any traffic during that period. This 
does look like an issue we need to look into, so having that detail 
would help.

-Jaikiran

On 08/11/25 9:53 pm, Josiah Noel wrote:
> Long time no see,
>
> I was trying a long running request with the new client and it seems 
> that after 30 seconds it cuts the request, regardless of whether I 
> specify a longer request timeout. Is there a different?mechanism for 
> configuration?
>
> -- 
> Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251110/3a242045/attachment-0001.htm>

From jaikiran.pai at oracle.com  Mon Nov 10 10:14:25 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Mon, 10 Nov 2025 15:44:25 +0530
Subject: Http 3 Client request timeout not respected
In-Reply-To: <37895ea9-3298-4843-8bf7-04986c0be342@oracle.com>
References: <CAJ_t5UZzWsGUmnt9Q5D1c26HM-8OpCptvt4OS92vw-VisxU9sA@mail.gmail.com>
 <37895ea9-3298-4843-8bf7-04986c0be342@oracle.com>
Message-ID: <24a227d5-4d41-48df-ac98-feb38b8ef8ad@oracle.com>

While at it, in your application could you also check what the server 
sends for the "max_idle_timeout" QUIC transport parameter 
https://www.rfc-editor.org/rfc/rfc9000#section-18.2-4.4.1? If that's not 
easy to locate, then you could enable (very verbose) logging of the 
JDK's HttpClient by setting the -Djdk.internal.httpclient.debug=true 
system property and rerunning the application. It will generate lots of 
logs, but you could search for "max_idle_timeout" or even "Received peer 
Quic transport params" text in that log.

-Jaikiran

On 10/11/25 3:29 pm, Jaikiran Pai wrote:
>
> Hello Josiah,
>
> Nov 08, 2025 11:15:41 AM jdk.internal.net.http.quic.QuicConnectionImpl 
> pushDatagram
> INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:4, size=75, 
> phase:-1, spin:-1, frames:[StreamFrame(stream=0, offset=0, length=2, 
> fin=false), StreamFrame(stream=0, offset=2, length=2, fin=false), 
> StreamFrame(stream=0, offset=4, length=34, fin=true)])
> ...
> INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task 
> unscheduled
> Nov 08, 2025 11:16:11 AM jdk.internal.net.http.quic.IdleTimeoutManager 
> idleTimedOut
>
> The long running request, is it generating any response during those 
> 30 seconds from the server to the client or is it handling the request 
> on the server side without generating any traffic during that period. 
> This does look like an issue we need to look into, so having that 
> detail would help.
>
> -Jaikiran
>
> On 08/11/25 9:53 pm, Josiah Noel wrote:
>> Long time no see,
>>
>> I was trying a long running request with the new client and it seems 
>> that after 30 seconds it cuts the request, regardless of whether I 
>> specify a longer request timeout. Is there a different?mechanism for 
>> configuration?
>>
>> -- 
>> Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251110/56bd1e7f/attachment.htm>

From dfuchs at openjdk.org  Mon Nov 10 10:33:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Nov 2025 10:33:06 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v4]
In-Reply-To: <-hcBnDkuvm6B_wcf48Jwdjj4DkHUlpxscvkbCQNOtI0=.2ac1d979-4401-45db-a1ed-21eaf7e7eb06@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
 <-hcBnDkuvm6B_wcf48Jwdjj4DkHUlpxscvkbCQNOtI0=.2ac1d979-4401-45db-a1ed-21eaf7e7eb06@github.com>
Message-ID: <idDHNpO74j2KAAHzcX5OQGSjyirIE10_Qhww1FSzT8M=.3fc29165-15c7-459e-938d-fe8cfb47c112@github.com>

On Sat, 8 Nov 2025 20:20:32 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback - request should fail
>
> src/java.net.http/share/classes/jdk/internal/net/http/common/Log.java line 394:
> 
>> 392:     public static void logError(Throwable t) {
>> 393:         if (errors()) {
>> 394:             logger.log(Level.INFO, "ERROR: " + t, t);
> 
> Suggestion:
> 
>             logger.log(Level.INFO, "ERROR:", t);

I'd rather not do that - this currently shows "ERROR: <exception-class> <message>" followed by a newline and the stack trace. Having just "ERROR: " on the line would look weird.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2509810870

From jpai at openjdk.org  Mon Nov 10 10:38:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 10:38:06 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v3]
In-Reply-To: <72Hqdp_vQ05Rjm7OADtB29pfqdcm-tVf7bOfNYCtcH8=.4949b35f-c582-49fd-9e22-c0f6393c00c7@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <joZtrdxNXWme7fLjL3JK4qZofJypbYqr8qSvkTJQalw=.427740f7-0fdd-4bd1-b60d-c32f693c5f0a@github.com>
 <vUzg4s4gO2dhtUZyI-hM4bp2MIY8J7IM8Y53RjM4-j8=.b0eea625-cc53-4848-be8f-a9e8845f26c1@github.com>
 <NND4YqP8AQi3XUM8tVhZI5cI-enjMBtMa2r6mj14cWw=.4455dc44-754d-439e-bae5-7104a9accc05@github.com>
 <72Hqdp_vQ05Rjm7OADtB29pfqdcm-tVf7bOfNYCtcH8=.4949b35f-c582-49fd-9e22-c0f6393c00c7@github.com>
Message-ID: <XwfK7FctUc-YqDja4r3SGzOfuybyejwFBsnhgCCuPWo=.e5667d99-3042-4d67-a917-1e4fd75641cd@github.com>

On Fri, 7 Nov 2025 17:58:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Oh sorry I meant to just remove this line. I thought it was better to not configure HTTP_3_URI_ONLY on the request in order to trigger the fallback on TCP. So something might actually respond. If something responds then we could get a response. On the other hand this might impacts other tests that might run on the machine...
>> hmmm... maybe I should fix that.
>
> The test now creates a TCP ServerSocket bound to the same port and which will close accepted connections. That should ensure safe fallback on TCP. If the ServerSocket cannot be created (address already in use) then the request will be configured with HTTP3_URI_ONLY to prevent fallback to TCP.

Hello Daniel, I think configuring the request to be just `HTTP3_URI_ONLY` and then verify that the request failed with this log message would be enough. But it's OK in the current proposed form too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28196#discussion_r2509830160

From jpai at openjdk.org  Mon Nov 10 10:38:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 10:38:04 GMT
Subject: RFR: 8371471: HttpClient: Log HTTP/3 handshake failures if logging
 errors is enabled [v4]
In-Reply-To: <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
 <gF2vFQAMArOqjFAlSflVHlB_Uk2fW44yXXG6ozr6D6k=.e281820f-8c6b-4779-8f4e-24883db45e86@github.com>
Message-ID: <YmSWBbeiEUi55cbZ1y1ugZrb6UcARkJl4ahjspaqk5o=.18d09608-77aa-46ee-90f7-9766e9225401@github.com>

On Fri, 7 Nov 2025 17:40:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback - request should fail

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28196#pullrequestreview-3442342722

From jpai at openjdk.org  Mon Nov 10 11:23:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 11:23:24 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
Message-ID: <rhHPxDahQvXPlXi2yZkiDiNyme5Ct8712OmxKqMB0Fs=.81ad2325-974d-4ff0-87f9-ed38639d908a@github.com>

On Fri, 7 Nov 2025 14:34:50 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated remaining callsites for new constants

test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 195:

> 193:                 0,
> 194:                 "/", exchange -> {
> 195:                     exchange.sendResponseHeaders(200, RSPBODY_EMPTY);

I'm guessing that this is intentionally using `RSPBODY_EMPTY` and previously it was a bug to send `0`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2510058472

From jpai at openjdk.org  Mon Nov 10 11:23:25 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 11:23:25 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <rhHPxDahQvXPlXi2yZkiDiNyme5Ct8712OmxKqMB0Fs=.81ad2325-974d-4ff0-87f9-ed38639d908a@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
 <rhHPxDahQvXPlXi2yZkiDiNyme5Ct8712OmxKqMB0Fs=.81ad2325-974d-4ff0-87f9-ed38639d908a@github.com>
Message-ID: <bemSe9rxZdy4qCT3PzL9QNl7UrX6Nk8VGOpqLq6xb7o=.8a02ff09-c4ff-4bf2-a0e3-f8a89547ebdd@github.com>

On Mon, 10 Nov 2025 11:20:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated remaining callsites for new constants
>
> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 195:
> 
>> 193:                 0,
>> 194:                 "/", exchange -> {
>> 195:                     exchange.sendResponseHeaders(200, RSPBODY_EMPTY);
> 
> I'm guessing that this is intentionally using `RSPBODY_EMPTY` and previously it was a bug to send `0`?

Never mind, I just heard the answer to this offline. This looks OK to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2510062036

From jpai at openjdk.org  Mon Nov 10 11:28:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 11:28:04 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
Message-ID: <kZEjbu3ywLm9vlrt99iaSksY2dY_uwxl4luHDZCK_TA=.b543a445-773f-479a-b225-6047b4f2c980@github.com>

On Fri, 7 Nov 2025 14:34:50 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated remaining callsites for new constants

test/jdk/com/sun/net/httpserver/bugs/8300268/MaxIdleConnectionsTest.java line 136:

> 134:             System.out.println("Sending response for request " + exchange.getRequestURI() + " from " + exchange.getRemoteAddress());
> 135:             reqFinishedProcessing.countDown();
> 136:             exchange.sendResponseHeaders(200, RSPBODY_CHUNKED);

Should this use `RSPBODY_EMPTY` instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2510082331

From jpai at openjdk.org  Mon Nov 10 11:36:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 11:36:31 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
Message-ID: <bQJBqrBgWUGI0lN6q90J0PDhNIOl000LbrAC5C3Q6LU=.c1611ff3-264b-4a6e-be2b-85ee73fbca00@github.com>

On Fri, 7 Nov 2025 14:34:50 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated remaining callsites for new constants

Overall this looks good to me. I just have one question which I've added inline.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28132#issuecomment-3511050324

From duke at openjdk.org  Mon Nov 10 11:50:07 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Mon, 10 Nov 2025 11:50:07 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v3]
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:

  Remove invalid host check in HostPortrange
  
  Removed check for leading ':' in host authority.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27896/files
  - new: https://git.openjdk.org/jdk/pull/27896/files/a4089913..17d1c7a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From jaikiran.pai at oracle.com  Mon Nov 10 11:58:13 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Mon, 10 Nov 2025 17:28:13 +0530
Subject: 8328894: HttpResponse.body() returns null with https target and
 failed proxy authentication
In-Reply-To: <E4B9618A-1427-44EF-97E4-721AAD8B147A@gmail.com>
References: <E4B9618A-1427-44EF-97E4-721AAD8B147A@gmail.com>
Message-ID: <bf4ca3ef-8647-43b6-95e9-7e6e8796f102@oracle.com>

Hello Hyunsu,

I haven't had a chance to take that one to completion. It looks like you 
have experimented with the issue as well as a fix. So yes, please go 
ahead and propose the PR (you'll have to sign the OCA first if you 
haven't already).

-Jaikiran

On 08/11/25 6:38 pm, Hyunsu Eun wrote:
> Hi,
>
> I noticed JDK-8328894 [1] has been open since March 2024 and would like
> to help if possible.
>
> I've analyzed the issue and created a potential fix that preserves the proxy
> response body for 407 authentication errors in HTTPS tunneling.
>
> The fix:
> - Changes CONNECT exchange from MultiExchange<Void> to MultiExchange<byte[]>
> - Caches the proxy response body and returns it through Exchange.readBodyAsync()
> - Adds a test case (ProxyAuthHttpsTest.java) to verify the behavior
>
> The root cause is that HTTPS uses CONNECT tunneling with a Void body type,
> and the 407 response body was being discarded via ignoreBody() instead of
> being preserved for the application.
>
> I've tested this locally and confirmed it addresses the issue:
> - Before: https:// with 407 returns null body
> - After: https:// with 407 returns body correctly (matching http:// behavior)
>
> I'd be happy to submit a PR or share more details about the approach if helpful.
>
> Thanks,
> Hyunsu Eun
>
> [1] https://bugs.openjdk.org/browse/JDK-8328894

From michaelm at openjdk.org  Mon Nov 10 12:25:44 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 10 Nov 2025 12:25:44 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v7]
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <z44UZKdarY5M1pc9GFlyNMYqW93rVvpGwKoDTgIjaOA=.9b6cb3f5-ad6d-469a-8f30-d44252b3d4fe@github.com>

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  Copyright header updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28132/files
  - new: https://git.openjdk.org/jdk/pull/28132/files/15f4179f..64073c68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28132&range=05-06

  Stats: 43 lines in 43 files changed: 0 ins; 0 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/28132.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28132/head:pull/28132

PR: https://git.openjdk.org/jdk/pull/28132

From jpai at openjdk.org  Mon Nov 10 13:02:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 13:02:37 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v7]
In-Reply-To: <z44UZKdarY5M1pc9GFlyNMYqW93rVvpGwKoDTgIjaOA=.9b6cb3f5-ad6d-469a-8f30-d44252b3d4fe@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <z44UZKdarY5M1pc9GFlyNMYqW93rVvpGwKoDTgIjaOA=.9b6cb3f5-ad6d-469a-8f30-d44252b3d4fe@github.com>
Message-ID: <U15TG4Ed7FCh6xADQ3SH3SFy8uE4rsyYoaWoUPfGChw=.fcdf066c-5cf0-4017-9899-3618801b90a5@github.com>

On Mon, 10 Nov 2025 12:25:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
>> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
>> 
>> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
>> 
>> Thanks,
>> Michael
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright header updates

The copyright year updates look good to me and so does the rest of this PR. I just have one comment here https://github.com/openjdk/jdk/pull/28132#discussion_r2510082331

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28132#pullrequestreview-3443142942

From dfuchs at openjdk.org  Mon Nov 10 13:08:20 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Nov 2025 13:08:20 GMT
Subject: Integrated: 8369920: HttpClient QuicSelectorThread could be a
 VirtualThread
In-Reply-To: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
References: <K8l8OauLtTYDyPQoCkHg0OL4t4SZSiyMfu2WAQlMlJA=.a3817c0f-879f-4492-8146-33db3a6b7c04@github.com>
Message-ID: <cDMwJCwbC4PhXYaEJG9B-HUBD_g2MpvzFgNCcmO2Aeg=.e10581ef-4270-4e97-a285-6c9ee2cd1dd3@github.com>

On Wed, 15 Oct 2025 15:58:23 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This change makes it possible to use a VirtualThread for the QuicSelectorThread. The default will be to use a VirtualThread on all platforms except the Windows platform. We might consider switching the default for Windows platform too once [JDK-8334574](https://bugs.openjdk.org/browse/JDK-8334574) is fixed.
> 
> The change should be transparent for users of the API. However, using a VirtualThread may result in subtle differences in thread scheduling and class loading, so this change also includes an escape hatch  (a non documented internal system property) that could be used to revert to a platform thread in case of unexpected issues.  That property may be removed in a future version of the JDK.

This pull request has now been integrated.

Changeset: 1142d299
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1142d299439bdf71de41b872a9b3d7775d0c692b
Stats:     287 lines in 3 files changed: 276 ins; 0 del; 11 mod

8369920: HttpClient QuicSelectorThread could be a VirtualThread

Reviewed-by: vyazici, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/27827

From jpai at openjdk.org  Mon Nov 10 13:16:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 13:16:06 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v3]
In-Reply-To: <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>
Message-ID: <-GnCVtYzbedCm4FSzVR3O7ew1mdG2EAF3ERE-wiNwI0=.37a25267-1bde-4f2a-99a3-ba9ad9f85405@github.com>

On Mon, 10 Nov 2025 11:50:07 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove invalid host check in HostPortrange
>   
>   Removed check for leading ':' in host authority.

src/java.base/share/classes/java/net/HostPortrange.java line 65:

> 63:         // Defensive validation first
> 64:         if (host == null || host.isEmpty()) {
> 65:             throw new IllegalArgumentException("empty authority");

Hello Oumaiyma, the change overall looks OK to me. However, this error message and the other one feel a bit odd. The variable is called `host` and we throw an "empty authority" here whereas the other place, the variable is called "authority" and we throw a error message which says "empty host". 

@dfuch do you suggest we switch these error messages?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27896#discussion_r2510530643

From josiahnoel at gmail.com  Mon Nov 10 13:38:32 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Mon, 10 Nov 2025 08:38:32 -0500
Subject: Http 3 Client request timeout not respected
Message-ID: <CAJ_t5UZmcA8+e5AGbMx9ctBt=GfZS4ea-1qzF=tAmLSRGLTH7w@mail.gmail.com>

To emulate a few of my worst case latency scenarios that I have seen in
production, I have added a sleep with a thirty second timer before I send a
200 status.

Once more I have attached my jbang script as well as the extended logs when
I ran with
-Djdk.httpclient.HttpClient.log=requests,headers,errors,http3,quic:control:retransmit.
-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251110/3e6b08d5/attachment.htm>
-------------- next part --------------
WARNING: Unknown module: io.avaje.jex.test specified to --add-reads
WARNING: Unknown module: io.avaje.spi.core specified to --add-reads
WARNING: Unknown module: io.avaje.spi specified to --add-reads
Nov 10, 2025 8:27:15 AM jdk.internal.net.http.Http3ClientImpl getConnectionFor
INFO: HTTP3: getConnectionFor exchange https://localhost:8080 GET #1
Nov 10, 2025 8:27:15 AM jdk.internal.net.http.Http3ClientImpl getConnectionFor
INFO: HTTP3: Creating connection for Exchange https://localhost:8080 GET #1
Nov 10, 2025 8:27:15 AM jdk.internal.net.http.HttpQuicConnection logAltSvcFor
INFO: ALTSVC: No AltService found for localhost:8080
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicClient chooseEndpoint
INFO: QUIC: Adding new endpoint: QuicEndpoint(HttpClientImpl(1)-0)
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicEndpoint lambda$create$1
INFO: QUIC: Initial receive buffer size is: 65536
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicEndpoint lambda$create$1
INFO: QUIC: Initial send buffer size is: 65536
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3Connection createAsync
INFO: HTTP3: Http3Connection.createAsync: Got HttpQuicConnection for https://localhost:8080 GET #1 is: quic:1
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicConnectionImpl startInitialTimer
INFO: QUIC: QuicClientConnection(1): Arming quic initial timer for PT29.999554S
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicConnectionImpl sendFirstInitialPacket
INFO: QUIC: QuicClientConnection(1): connectionId: ffff4b91840a9a62d8685e, QuicEndpoint(HttpClientImpl(1)-0): QuicEndpoint(HttpClientImpl(1)-0) - /[0:0:0:0:0:0:0:0]:54039
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.IdleTimeoutManager checkUpdateIdleTimeout
INFO: QUIC: QuicClientConnection(1) idle connection timeout updated to 30,000 milli seconds
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): INITIAL no deadline, task unscheduled
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space INITIAL
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.IdleTimeoutManager startIdleTerminationTimer
INFO: QUIC: QuicClientConnection(1) started QUIC idle timeout management for connection, idle timeout event: QuicIdleTimeoutEvent-4 deadline: Deadline(2025-11-10T13:27:46.296992600Z)
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.IdleTimeoutManager startStreamDataBlockedTimer
INFO: QUIC: QuicClientConnection(1) started STREAM_DATA_BLOCKED timer for connection, event: StreamDataBlockedEvent-5 deadline: Deadline(2025-11-10T13:27:38.798481900Z)
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3Connection <init>
INFO: HTTP3: HTTP/3 connection created for QuicClientConnection(1) - local address: /[0:0:0:0:0:0:0:0]:54039
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicConnectionImpl processDecrypted
INFO: QUIC: QuicClientConnection(1) IN: ONERTT(pn:0, size=35, phase:0, spin:0, frames:[HandshakeDoneFrame, StreamFrame(stream=3, offset=0, length=1, fin=false)])
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicConnectionImpl pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:0, size=92, phase:-1, spin:-1, frames:[NewConnectionIDFrame(seqNumber=1, retirePriorTo=0, connIdLength=11), StreamFrame(stream=2, offset=0, length=1, fin=false), StreamFrame(stream=2, offset=1, length=27, fin=false)])
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.AltServicesRegistry registerUnadvertised
INFO: ALTSVC: Added unadvertised AltService: Optional[AltSvc: h3="localhost:8080"; origin="https://localhost:8080"; deadline=Deadline(2025-11-11T13:27:16.330910300Z); persist=true; advertised=false; sameAuthorityAsOrigin=true;]
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space HANDSHAKE
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3ClientImpl connectionCompleted
INFO: HTTP3: Checking waiters on completed connection quic:1 to https:localhost:8080 created for https://localhost:8080 GET #1
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): HANDSHAKE no deadline, task unscheduled
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3ClientImpl connectionCompleted0
INFO: HTTP3: Connection creation completed for requests to https:localhost:8080: waiters[0](completed:0, retried:0, errors:0) - originally created for https://localhost:8080 GET #1
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicConnectionImpl processDecrypted
INFO: QUIC: QuicClientConnection(1) IN: ONERTT(pn:2, size=102, phase:0, spin:0, frames:[NewConnectionIDFrame(seqNumber=1, retirePriorTo=0, connIdLength=8), CryptoFrame(offset=0, length=42)])
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3Connection createHttp3ExchangeImpl
INFO: HTTP3: Creating HTTP/3 exchange for QuicClientConnection(1)/streamId=0
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3ExchangeImpl start
INFO: HTTP3: Starting HTTP/3 exchange for QuicClientConnection(1)/streamId=0 (https://localhost:8080 GET #1)
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3ExchangeImpl sendHeaders
INFO: REQUEST: https://localhost:8080 GET
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.Http3ExchangeImpl sendHeaders
INFO: HEADERS: H3 HEADERS FRAME (stream=0)
    :authority: localhost:8080
    :method: GET
    :path: /
    :scheme: https
    User-Agent: Java-http-client/26-ea


Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.QuicConnectionImpl pushDatagram
INFO: QUIC: QuicClientConnection(1) OUT: ONERTT(pn:3, size=75, phase:-1, spin:-1, frames:[StreamFrame(stream=0, offset=0, length=2, fin=false), StreamFrame(stream=0, offset=2, length=2, fin=false), StreamFrame(stream=0, offset=4, length=34, fin=true)])
Nov 10, 2025 8:27:16 AM jdk.internal.net.http.quic.PacketSpaceManager$PacketTransmissionTask logNoDeadline
INFO: QUIC: QuicClientConnection(1): APPLICATION no deadline, task unscheduled
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.quic.IdleTimeoutManager idleTimedOut
INFO: QUIC: QuicClientConnection(1) silently terminating connection due to idle timeout (30000 milli seconds): 
  PacketSpace: INITIAL
    State: closed
    AckFrame: NextAckFrame[ackFrame=AckFrame(largestAcknowledged=0, ackDelay=0, ackRanges=[0..0]), deadline=Deadline(+1000000000-12-31T23:59:59.999999999Z), lastUpdated=Deadline(2025-11-10T13:27:16.260596800Z), sent=Deadline(2025-11-10T13:27:16.261160100Z)]
    Pending acks: ()
    Pending retransmit: ()
  PacketSpace: HANDSHAKE
    State: closed
    AckFrame: NextAckFrame[ackFrame=AckFrame(largestAcknowledged=3, ackDelay=0, ackRanges=[0..3]), deadline=Deadline(+1000000000-12-31T23:59:59.999999999Z), lastUpdated=Deadline(2025-11-10T13:27:16.296091200Z), sent=Deadline(2025-11-10T13:27:16.296880300Z)]
    Pending acks: ()
    Pending retransmit: ()
  PacketSpace: APPLICATION
    State: opened
    AckFrame: NextAckFrame[ackFrame=AckFrame(largestAcknowledged=4, ackDelay=0, ackRanges=[0..4]), deadline=Deadline(+1000000000-12-31T23:59:59.999999999Z), lastUpdated=Deadline(2025-11-10T13:27:16.391776500Z), sent=Deadline(2025-11-10T13:27:16.401712Z)]
    Pending acks: ()
    Pending retransmit: ()
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.quic.ConnectionTerminatorImpl silentTerminate
INFO: QUIC: QuicClientConnection(1) silently terminating connection due to: connection idle timed out (30000 milli seconds)
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.quic.ConnectionTerminatorImpl silentTerminate
INFO: QUIC: QuicClientConnection(1) connection state: sending: {canSend:false, credit: 9999934, sendersReady: false, hasControlFrames: false}, cc: { backoff: 1, duration: PT0.16572S, current deadline: due since 30001ms, prospective deadline: not scheduled (Deadline.MAX)}, streams: [{id:0, available: 0, blocked: false},]
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.quic.PacketSpaceManager close
INFO: QUIC: QuicClientConnection(1) closing packet space APPLICATION
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.Http3ExchangeImpl onPollException
INFO: HTTP3: QuicClientConnection(1)/streamId=0 https://localhost:8080 GET #1 (requestSent=true, responseReceived=false, reader=RECV, writer=DATA_RECVD, statusCode=0, finalStream=false, receivedQuicBytes=0, sentQuicBytes=38): java.io.IOException: connection idle timed out (30000 milli seconds)
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.Http3ExchangeImpl close
INFO: HTTP3: Closed HTTP/3 exchange for QuicClientConnection(1)/streamId=0 with error java.io.IOException: connection idle timed out (30000 milli seconds)
Nov 10, 2025 8:27:46 AM jdk.internal.net.http.Http3Connection onExchangeClose
INFO: HTTP3: HTTP/3 connection QuicClientConnection(1) left open: exchanged streamId=0 closed; finalStream=false, exchangeStreams=0, reservedStreamCount=0
Exception in thread "main" java.io.IOException: connection idle timed out (30000 milli seconds)
	at java.net.http/jdk.internal.net.http.HttpClientImpl.send(HttpClientImpl.java:1018)
	at java.net.http/jdk.internal.net.http.HttpClientFacade.send(HttpClientFacade.java:133)
	at io.avaje.jex.http3.flupke/io.avaje.jex.http3.flupke.Timeout.main(Timeout.java:99)
Caused by: java.io.IOException: connection idle timed out (30000 milli seconds)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.toReportedCause(TerminationCause.java:129)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.<init>(TerminationCause.java:56)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause$SilentTermination.<init>(TerminationCause.java:203)
	at java.net.http/jdk.internal.net.http.quic.TerminationCause.forSilentTermination(TerminationCause.java:96)
	at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager.idleTimedOut(IdleTimeoutManager.java:349)
	at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager$IdleTimeoutEvent.terminateNow(IdleTimeoutManager.java:437)
	at java.net.http/jdk.internal.net.http.quic.IdleTimeoutManager$IdleTimeoutEvent.handle(IdleTimeoutManager.java:411)
	at java.net.http/jdk.internal.net.http.quic.QuicTimerQueue.processDue(QuicTimerQueue.java:298)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$LockingRestartableTask.run(SequentialScheduler.java:182)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$CompleteRestartableTask.run(SequentialScheduler.java:149)
	at java.net.http/jdk.internal.net.http.common.SequentialScheduler$SchedulableTask.run(SequentialScheduler.java:207)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
	at java.base/java.lang.Thread.run(Thread.java:1474)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Timeout.java
Type: application/octet-stream
Size: 3839 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251110/3e6b08d5/Timeout.java>

From michaelm at openjdk.org  Mon Nov 10 13:40:11 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 10 Nov 2025 13:40:11 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <bemSe9rxZdy4qCT3PzL9QNl7UrX6Nk8VGOpqLq6xb7o=.8a02ff09-c4ff-4bf2-a0e3-f8a89547ebdd@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
 <rhHPxDahQvXPlXi2yZkiDiNyme5Ct8712OmxKqMB0Fs=.81ad2325-974d-4ff0-87f9-ed38639d908a@github.com>
 <bemSe9rxZdy4qCT3PzL9QNl7UrX6Nk8VGOpqLq6xb7o=.8a02ff09-c4ff-4bf2-a0e3-f8a89547ebdd@github.com>
Message-ID: <tLUf3WWY0b5rU9fdfJKk668bkY40YPspgHhfb78FajM=.6e3caa75-bdf8-4bc7-9e3a-49bd2c12683c@github.com>

On Mon, 10 Nov 2025 11:20:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 195:
>> 
>>> 193:                 0,
>>> 194:                 "/", exchange -> {
>>> 195:                     exchange.sendResponseHeaders(200, RSPBODY_EMPTY);
>> 
>> I'm guessing that this is intentionally using `RSPBODY_EMPTY` and previously it was a bug to send `0`?
>
> Never mind, I just heard the answer to this offline. This looks OK to me.

Hi Jaikiran. I think `0` was probably not intended. I decided to "fix" it in this place, but leave it in the others

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2510602379

From michaelm at openjdk.org  Mon Nov 10 13:40:14 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 10 Nov 2025 13:40:14 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <kZEjbu3ywLm9vlrt99iaSksY2dY_uwxl4luHDZCK_TA=.b543a445-773f-479a-b225-6047b4f2c980@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
 <kZEjbu3ywLm9vlrt99iaSksY2dY_uwxl4luHDZCK_TA=.b543a445-773f-479a-b225-6047b4f2c980@github.com>
Message-ID: <k3CxXShqLMKAo7OcRJ1uKSxvXglXywkn0tAqXaqUGZE=.9a54ba1f-f48c-481e-a522-9a1077450910@github.com>

On Mon, 10 Nov 2025 11:24:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated remaining callsites for new constants
>
> test/jdk/com/sun/net/httpserver/bugs/8300268/MaxIdleConnectionsTest.java line 136:
> 
>> 134:             System.out.println("Sending response for request " + exchange.getRequestURI() + " from " + exchange.getRemoteAddress());
>> 135:             reqFinishedProcessing.countDown();
>> 136:             exchange.sendResponseHeaders(200, RSPBODY_CHUNKED);
> 
> Should this use `RSPBODY_EMPTY` instead?

As noted above, I decided to change it in one place, but leave it as is, in others.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2510609035

From jpai at openjdk.org  Mon Nov 10 13:47:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 10 Nov 2025 13:47:22 GMT
Subject: RFR: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability [v6]
In-Reply-To: <k3CxXShqLMKAo7OcRJ1uKSxvXglXywkn0tAqXaqUGZE=.9a54ba1f-f48c-481e-a522-9a1077450910@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
 <1khOLl95h3mh-2HrkPgha3dqqRMZxP8DgwfKAxZRDEk=.940225a6-2762-49a7-a66c-cbdb4a64f1e9@github.com>
 <kZEjbu3ywLm9vlrt99iaSksY2dY_uwxl4luHDZCK_TA=.b543a445-773f-479a-b225-6047b4f2c980@github.com>
 <k3CxXShqLMKAo7OcRJ1uKSxvXglXywkn0tAqXaqUGZE=.9a54ba1f-f48c-481e-a522-9a1077450910@github.com>
Message-ID: <yQB3ZoP9xeA4hQ-WKhj3ZAHFGE5Zkvx4xzf9rJA1HKU=.eebe7742-5317-418f-b225-8997199a1ede@github.com>

On Mon, 10 Nov 2025 13:37:05 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> test/jdk/com/sun/net/httpserver/bugs/8300268/MaxIdleConnectionsTest.java line 136:
>> 
>>> 134:             System.out.println("Sending response for request " + exchange.getRequestURI() + " from " + exchange.getRemoteAddress());
>>> 135:             reqFinishedProcessing.countDown();
>>> 136:             exchange.sendResponseHeaders(200, RSPBODY_CHUNKED);
>> 
>> Should this use `RSPBODY_EMPTY` instead?
>
> As noted above, I decided to change it in one place, but leave it as is, in others.

Thank you Michael. That's fine with me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28132#discussion_r2510636634

From jaikiran.pai at oracle.com  Mon Nov 10 14:01:33 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Mon, 10 Nov 2025 19:31:33 +0530
Subject: Http 3 Client request timeout not respected
In-Reply-To: <CAJ_t5UZmcA8+e5AGbMx9ctBt=GfZS4ea-1qzF=tAmLSRGLTH7w@mail.gmail.com>
References: <CAJ_t5UZmcA8+e5AGbMx9ctBt=GfZS4ea-1qzF=tAmLSRGLTH7w@mail.gmail.com>
Message-ID: <cea1235b-5641-4e9f-b68c-a5180aa55684@oracle.com>

Looking at the application code, the relevant parts appear to be this:

ServerConnectionConfig.builder()
 ??????? .maxIdleTimeoutInSeconds(50)
...
new Http3ApplicationProtocolFactory(
 ??? (request, response) -> {
 ????? try {
 ??????? Thread.sleep(Duration.ofSeconds(40));
 ????? } catch (InterruptedException e) {
 ??????? Thread.interrupted();
 ????? }
 ????? response.setStatus(200);
...
HttpClient.newBuilder()
 ? .version(Version.valueOf("HTTP_3"))
 ? .sslContext(sslContext)
 ? .build()
 ? .send(
 ????? HttpRequest.newBuilder()
 ????????? .timeout(Duration.ofSeconds(45))
 ????????? .uri(URI.create("https://localhost:8080"))
 ????????? .GET()

The server is configured to have a QUIC idle timeout of 50 seconds. On 
the client side, the JDK's HttpClient for HTTP/3 by default uses a idle 
timeout of 30 seconds. These timeouts translate to the QUIC connection 
level idle timeouts, which decide when to terminate the connection if 
there's no UDP traffic on that connection. The QUIC RFC specifies that 
each of the endpoints (the server and the client) can choose to 
advertise a idle timeout of their own, but the negotiated idle timeout 
will always be the lower of those two and that negotiated timeout must 
be honoured by both sides of the connection. So in this case, the server 
advertises 50 seconds and the client advertises 30 seconds, so the 30 
second timeout is the negotiated one for this connection and thus if the 
connection doesn't generate any traffic for that duration (like in this 
case), it gets idle terminated.

The default idle timeout for JDK's HttpClient can be configured using 
the "jdk.httpclient.keepalive.timeout.h3" system property 
https://download.java.net/java/early_access/jdk26/docs/api/java.net.http/module-summary.html. 
So setting it to -Djdk.httpclient.keepalive.timeout.h3=50 (for example), 
should then allow your application to stay idle without generating any 
UDP traffic for the QUIC connection for that long.

-Jaikiran

On 10/11/25 7:08 pm, Josiah Noel wrote:
> To emulate a few of my worst case latency scenarios that?I?have seen 
> in production, I have added a sleep with a thirty second timer before 
> I send a 200 status.
>
> Once more I have attached?my jbang script as well as the extended logs 
> when I ran with 
> -Djdk.httpclient.HttpClient.log=requests,headers,errors,http3,quic:control:retransmit.
> -- 
> Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251110/a06a20f9/attachment-0001.htm>

From michaelm at openjdk.org  Mon Nov 10 14:37:36 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Mon, 10 Nov 2025 14:37:36 GMT
Subject: Integrated: 8331195: Improve com.sun.net.httpserver.HttpExchange
 usability
In-Reply-To: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
References: <oEA6-m36n0vdpWBTcf-fHskp78Dxg_37xMGLj7Elodo=.ab502b84-359d-477a-80dd-f14bebdd0e8b@github.com>
Message-ID: <1h_PdqZlThKoSVmGbRnjCzAYrNTvpZR6wr94lamfrlw=.933e1c76-4fa9-4c84-b5d6-e87378651da4@github.com>

On Tue, 4 Nov 2025 14:10:14 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I'd like to return to this issue with a new PR that addresses the usability issue minimally. Namely to define numeric constants
> for the counter-intuitive responseLength values in `HttpExchange.sendResponseHeaders`. The apidoc then refers to the constant names rather than the numeric values.
> 
> I've updated the implementation and some tests (though not all yet) to use the constant names. I'm open to suggestions on the names themselves. Once that is agreed, I'll update the remaining tests and any other call sites in the implementation.
> 
> Thanks,
> Michael

This pull request has now been integrated.

Changeset: 1877ff99
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1877ff996b67849205fd6cde1285461c4db1b359
Stats:     213 lines in 48 files changed: 84 ins; 3 del; 126 mod

8331195: Improve com.sun.net.httpserver.HttpExchange usability

Reviewed-by: jpai, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28132

From dfuchs at openjdk.org  Mon Nov 10 16:58:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Nov 2025 16:58:25 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <E_pI4okmg4Nd_mSOsL197YCHJ84WSmO1zmgJvihA6Ig=.d3b6e2b4-bd48-46de-85ee-9521fe9d502b@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
 <E_pI4okmg4Nd_mSOsL197YCHJ84WSmO1zmgJvihA6Ig=.d3b6e2b4-bd48-46de-85ee-9521fe9d502b@github.com>
Message-ID: <hql6f0ssbC8ktwI5RLS4b2cFkX8-t9vau5pCpBSzUjY=.43e1675b-a5ce-4ec4-8c01-828be25359da@github.com>

On Fri, 7 Nov 2025 18:14:38 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> I haven't study the test in depth, but it smells like a race condition/conditions

hmmm... I believe you're right. Let me have a deeper look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3512820479

From dfuchs at openjdk.org  Mon Nov 10 17:32:38 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Nov 2025 17:32:38 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v3]
In-Reply-To: <-GnCVtYzbedCm4FSzVR3O7ew1mdG2EAF3ERE-wiNwI0=.37a25267-1bde-4f2a-99a3-ba9ad9f85405@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>
 <-GnCVtYzbedCm4FSzVR3O7ew1mdG2EAF3ERE-wiNwI0=.37a25267-1bde-4f2a-99a3-ba9ad9f85405@github.com>
Message-ID: <eCmjIJizVKjOl45IhMgQjLXUJ63uqQwao6oiXVZRiGI=.2d531149-c62d-4117-a3f7-8799d27b8315@github.com>

On Mon, 10 Nov 2025 13:12:57 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove invalid host check in HostPortrange
>>   
>>   Removed check for leading ':' in host authority.
>
> src/java.base/share/classes/java/net/HostPortrange.java line 65:
> 
>> 63:         // Defensive validation first
>> 64:         if (host == null || host.isEmpty()) {
>> 65:             throw new IllegalArgumentException("empty authority");
> 
> Hello Oumaiyma, the change overall looks OK to me. However, this error message and the other one feel a bit odd. The variable is called `host` and we throw an "empty authority" here whereas the other place, the variable is called "authority" and we throw a error message which says "empty host". 
> 
> @dfuch do you suggest we switch these error messages?

We should probably throw the same exception here than below:


throw new IllegalArgumentException("Invalid URL authority: empty host");


If the authority is empty the host is a fortiori empty too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27896#discussion_r2511391270

From dfuchs at openjdk.org  Mon Nov 10 17:59:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 10 Nov 2025 17:59:54 GMT
Subject: Integrated: 8371471: HttpClient: Log HTTP/3 handshake failures if
 logging errors is enabled
In-Reply-To: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
References: <pAZD_mb58Xm3yc4Slym2koaElytOUE7dpa40KThufro=.d0f93612-34f4-4324-9907-7d1a5395d318@github.com>
Message-ID: <Ki4ZmgcwLWpk58OF6ax0uk_7yR-VICqHedgKBpaQvkA=.4b9be7ae-bcdc-4e74-89ce-94f5608d1297@github.com>

On Fri, 7 Nov 2025 14:19:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Surprisingly if the QUIC handshake fails exceptionally, and `-Djdk.httpclient.HttpClient.log=errors` is specified, the exception is not logged. This change fixes that.

This pull request has now been integrated.

Changeset: 8a911aed
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a911aed26211936a9c2652299a1bca8a06cae21
Stats:     229 lines in 3 files changed: 226 ins; 1 del; 2 mod

8371471: HttpClient: Log HTTP/3 handshake failures if logging errors is enabled

Reviewed-by: djelinski, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28196

From jaikiran.pai at oracle.com  Tue Nov 11 05:22:40 2025
From: jaikiran.pai at oracle.com (Jaikiran Pai)
Date: Tue, 11 Nov 2025 10:52:40 +0530
Subject: Http 3 Client request timeout not respected
In-Reply-To: <cea1235b-5641-4e9f-b68c-a5180aa55684@oracle.com>
References: <CAJ_t5UZmcA8+e5AGbMx9ctBt=GfZS4ea-1qzF=tAmLSRGLTH7w@mail.gmail.com>
 <cea1235b-5641-4e9f-b68c-a5180aa55684@oracle.com>
Message-ID: <631b2f04-dc33-4b34-aed9-32e56c8a6886@oracle.com>

Hello Josiah,

In my previous mail, I mentioned an incorrect system property to 
configure for the timeout. The right one is 
"jdk.httpclient.quic.idleTimeout". This one too takes a value in 
seconds. So configuring it to "-Djdk.httpclient.quic.idleTimeout=50" 
(for example) would be useful in the application code you are 
experimenting with. Let us know how it works out.

-Jaikiran

On 10/11/25 7:31 pm, Jaikiran Pai wrote:
>
> Looking at the application code, the relevant parts appear to be this:
>
> ServerConnectionConfig.builder()
> ??????? .maxIdleTimeoutInSeconds(50)
> ...
> new Http3ApplicationProtocolFactory(
> ??? (request, response) -> {
> ????? try {
> ??????? Thread.sleep(Duration.ofSeconds(40));
> ????? } catch (InterruptedException e) {
> ??????? Thread.interrupted();
> ????? }
> ????? response.setStatus(200);
> ...
> HttpClient.newBuilder()
> ? .version(Version.valueOf("HTTP_3"))
> ? .sslContext(sslContext)
> ? .build()
> ? .send(
> ????? HttpRequest.newBuilder()
> ????????? .timeout(Duration.ofSeconds(45))
> ????????? .uri(URI.create("https://localhost:8080"))
> ????????? .GET()
>
> The server is configured to have a QUIC idle timeout of 50 seconds. On 
> the client side, the JDK's HttpClient for HTTP/3 by default uses a 
> idle timeout of 30 seconds. These timeouts translate to the QUIC 
> connection level idle timeouts, which decide when to terminate the 
> connection if there's no UDP traffic on that connection. The QUIC RFC 
> specifies that each of the endpoints (the server and the client) can 
> choose to advertise a idle timeout of their own, but the negotiated 
> idle timeout will always be the lower of those two and that negotiated 
> timeout must be honoured by both sides of the connection. So in this 
> case, the server advertises 50 seconds and the client advertises 30 
> seconds, so the 30 second timeout is the negotiated one for this 
> connection and thus if the connection doesn't generate any traffic for 
> that duration (like in this case), it gets idle terminated.
>
> The default idle timeout for JDK's HttpClient can be configured using 
> the "jdk.httpclient.keepalive.timeout.h3" system property 
> https://download.java.net/java/early_access/jdk26/docs/api/java.net.http/module-summary.html. 
> So setting it to -Djdk.httpclient.keepalive.timeout.h3=50 (for 
> example), should then allow your application to stay idle without 
> generating any UDP traffic for the QUIC connection for that long.
>
> -Jaikiran
>
> On 10/11/25 7:08 pm, Josiah Noel wrote:
>> To emulate a few of my worst case latency scenarios that?I?have seen 
>> in production, I have added a sleep with a thirty second timer before 
>> I send a 200 status.
>>
>> Once more I have attached?my jbang script as well as the extended 
>> logs when I ran with 
>> -Djdk.httpclient.HttpClient.log=requests,headers,errors,http3,quic:control:retransmit.
>> -- 
>> Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251111/cb89d5d9/attachment.htm>

From michaelm at openjdk.org  Tue Nov 11 10:17:12 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 11 Nov 2025 10:17:12 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v3]
In-Reply-To: <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>
Message-ID: <8xUXoADAZoft0-yBHf8XgTajv3KvUS1dKp3PdQAnqjg=.23b54987-f650-4dfa-92e3-374aee4fe23e@github.com>

On Mon, 10 Nov 2025 11:50:07 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove invalid host check in HostPortrange
>   
>   Removed check for leading ':' in host authority.

Changes requested by michaelm (Reviewer).

src/java.base/share/classes/java/net/URLPermission.java line 532:

> 530:             if (authority == null || authority.isEmpty()) {
> 531:                 throw new IllegalArgumentException("Invalid URL authority: empty host");
> 532:             }

Suggestion:

            if (authority == null || authority.isEmpty()) {
                throw new IllegalArgumentException("Invalid URL: authority is empty");
            }

-------------

PR Review: https://git.openjdk.org/jdk/pull/27896#pullrequestreview-3447279412
PR Review Comment: https://git.openjdk.org/jdk/pull/27896#discussion_r2513622303

From michaelm at openjdk.org  Tue Nov 11 10:17:15 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 11 Nov 2025 10:17:15 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v3]
In-Reply-To: <eCmjIJizVKjOl45IhMgQjLXUJ63uqQwao6oiXVZRiGI=.2d531149-c62d-4117-a3f7-8799d27b8315@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <tnuOvmLId1sWvNoJ-uR4Sk87kIl1Q4HwRbdnPm7w5xw=.91d3d492-0984-4a0a-833c-56cfd7abd388@github.com>
 <-GnCVtYzbedCm4FSzVR3O7ew1mdG2EAF3ERE-wiNwI0=.37a25267-1bde-4f2a-99a3-ba9ad9f85405@github.com>
 <eCmjIJizVKjOl45IhMgQjLXUJ63uqQwao6oiXVZRiGI=.2d531149-c62d-4117-a3f7-8799d27b8315@github.com>
Message-ID: <Bn22dUJZeZ7LS3r64-2l1NOBkgEFET7uO7mPh4msn6I=.13e0d2e3-0761-4bb4-a643-7692e2c8a0d5@github.com>

On Mon, 10 Nov 2025 17:29:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/HostPortrange.java line 65:
>> 
>>> 63:         // Defensive validation first
>>> 64:         if (host == null || host.isEmpty()) {
>>> 65:             throw new IllegalArgumentException("empty authority");
>> 
>> Hello Oumaiyma, the change overall looks OK to me. However, this error message and the other one feel a bit odd. The variable is called `host` and we throw an "empty authority" here whereas the other place, the variable is called "authority" and we throw a error message which says "empty host". 
>> 
>> @dfuch do you suggest we switch these error messages?
>
> We should probably throw the same exception here than below:
> 
> 
> throw new IllegalArgumentException("Invalid URL authority: empty host");
> 
> 
> If the authority is empty the host is a fortiori empty too.

Technically (and as one of the test cases shows) the authority might not be empty, but the "host port" part is empty. I think "Invalid URL authority" might be okay though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27896#discussion_r2513634883

From duke at openjdk.org  Tue Nov 11 11:39:03 2025
From: duke at openjdk.org (EunHyunsu)
Date: Tue, 11 Nov 2025 11:39:03 GMT
Subject: RFR: 8357554: HttpResponse.body() returns null with https target and
 failed proxy authentication
Message-ID: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>

### Summary
  This patch addresses the issue where `HttpResponse.body()` returns `null` for 407 responses when using HTTPS through a proxy, while HTTP requests correctly return the response body.

  ### Problem
  When an HTTPS request receives a 407 Proxy Authentication Required response, the response body is discarded during CONNECT tunnel establishment. This is inconsistent with HTTP behavior where the body is properly returned.

  **Root cause:**
  - HTTPS uses `MultiExchange<Void>` for CONNECT requests
  - The body is explicitly ignored via `ignoreBody()` on 407 responses
  - No mechanism exists to preserve the body for later retrieval

  ### Proposed Solution
  I propose the following changes to preserve and return the 407 response body:

  1. **PlainTunnelingConnection.java**: Change `MultiExchange<Void>` to `MultiExchange<byte[]>` and read the body on 407 responses instead of ignoring it

  2. **ProxyAuthenticationRequired.java**: Add `proxyResponseBody` field to carry the body bytes through the exception

  3. **Exchange.java**: Cache both the proxy response and body, then return them when the application calls `body()`

  ### Testing
  Added comprehensive test (`ProxyAuthHttpTest.java`) covering:
  - Basic HTTP and HTTPS 407 responses
  - Multiple `BodyHandler` types: `ofString()`, `ofByteArray()`, `ofInputStream()`, `ofLines()`
  - Response headers validation

  **Test results**: 38/38 passed

  ### Notes
  - This change only affects 407 responses; all other flows remain unchanged
  - The cached body is cleared after first use to prevent reuse
  - No changes to public APIs; internal implementation only

  I'd appreciate any feedback on this approach. If there's a better way to handle this, I'm happy to revise.

-------------

Commit messages:
 - 8328894: Add test for 407 response body with various handlers
 - 8328894: Cache and return 407 response body to application
 - 8328894: Add proxyResponseBody field to preserve 407 body
 - 8328894: Read 407 response body in HTTPS CONNECT tunneling

Changes: https://git.openjdk.org/jdk/pull/28232/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28232&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8357554
  Stats: 372 lines in 4 files changed: 301 ins; 8 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/28232.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28232/head:pull/28232

PR: https://git.openjdk.org/jdk/pull/28232

From jpai at openjdk.org  Tue Nov 11 13:05:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Nov 2025 13:05:09 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using http/2
Message-ID: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>

Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?

I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.

A new jtreg test has been introduced which reproduces the issue and verifies the fix.

-------------

Commit messages:
 - cleanup
 - update test
 - Return false from isOpen() if underlying channel is not open
 - Daniel's review suggestion - stop the scheduler when TubeSubscriber errored or completed
 - introduce a test to reproduce the leak and verify the fix
 - 8326498: java.net.http.HttpClient connection leak using http/2

Changes: https://git.openjdk.org/jdk/pull/28233/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8326498
  Stats: 960 lines in 9 files changed: 695 ins; 118 del; 147 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From dfuchs at openjdk.org  Tue Nov 11 14:04:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Nov 2025 14:04:22 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <sMV_UOCFlq2wzXkFXbwZj3AIlAu6ZqLD_jaHBYa02jQ=.3d9a0dd7-a3d7-427e-bae9-ef47c050ccd1@github.com>

On Tue, 11 Nov 2025 12:58:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 912:

> 910:      * Closes the connection normally (with a NO_ERROR termination cause), if not already closed.
> 911:      */
> 912:     final void close() {

Maybe we should mark the Http2Connection as Closeable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2514204634

From dfuchs at openjdk.org  Tue Nov 11 14:06:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Nov 2025 14:06:54 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v2]
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <-H6DxtM58nM6qRwf20uCcEc9zNRtdqxsVbW2yluPOgc=.5a78599a-b77b-410a-8829-99ba3f39dd73@github.com>

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Review feedback: increasing the timeout might not help
 - Merge branch 'master' into RawChannel-8371366
 - 8371366: java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in jtreg timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28178/files
  - new: https://git.openjdk.org/jdk/pull/28178/files/e7b8305b..0ae487b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=00-01

  Stats: 149218 lines in 708 files changed: 103007 ins; 19058 del; 27153 mod
  Patch: https://git.openjdk.org/jdk/pull/28178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28178/head:pull/28178

PR: https://git.openjdk.org/jdk/pull/28178

From jpai at openjdk.org  Tue Nov 11 14:18:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Nov 2025 14:18:56 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - mark jdk.internal.net.http.Http2Connection as Closable
 - reduce number of concurrent requests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/6c983026..3e4574b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=00-01

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Tue Nov 11 14:19:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 11 Nov 2025 14:19:00 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <sMV_UOCFlq2wzXkFXbwZj3AIlAu6ZqLD_jaHBYa02jQ=.3d9a0dd7-a3d7-427e-bae9-ef47c050ccd1@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <sMV_UOCFlq2wzXkFXbwZj3AIlAu6ZqLD_jaHBYa02jQ=.3d9a0dd7-a3d7-427e-bae9-ef47c050ccd1@github.com>
Message-ID: <zs6OONpEOaOlfy8KH-uGxreqsjVTnr8vEv6dKBVc_Fo=.c8c54bae-91c4-4a08-994c-df481bb38ee6@github.com>

On Tue, 11 Nov 2025 13:17:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 912:
> 
>> 910:      * Closes the connection normally (with a NO_ERROR termination cause), if not already closed.
>> 911:      */
>> 912:     final void close() {
> 
> Maybe we should mark the Http2Connection as Closeable.

I think that's reasonable. I've updated the PR to include this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2514406165

From dfuchs at openjdk.org  Tue Nov 11 14:22:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Nov 2025 14:22:49 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <E_pI4okmg4Nd_mSOsL197YCHJ84WSmO1zmgJvihA6Ig=.d3b6e2b4-bd48-46de-85ee-9521fe9d502b@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
 <E_pI4okmg4Nd_mSOsL197YCHJ84WSmO1zmgJvihA6Ig=.d3b6e2b4-bd48-46de-85ee-9521fe9d502b@github.com>
Message-ID: <pJ11Qs7wbp10nl4Y3pk9JEUluKYaRjCW3KpODfvMQCY=.0183aab5-c633-4755-80db-abd9cd0a24b4@github.com>

On Fri, 7 Nov 2025 18:14:38 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
>> 
>> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.
>
> It is fine to increase the jtreg test timeout. BUT with the TIMEOUT FACTOR reverted to 4 and hence  an overall jtreg timeout 8 minutes, the most likely outcome of increasing the test's explicit timeout to 240 is for the test to timeout after 16 minutes, when this "moribund" condition arises. Take into account that a typical execution time in CI is < 20 seconds
> And is < 4 seconds on laptop.
> 
> The process capture suggests that the writer and reader in the readSlowly and writeSlowly have got stuck  
> It's a complex enough test with the HttpClient also stuck in a "poll" waiting on network events
> I haven't study the test in depth, but it smells like a race condition/conditions

Taking into account the observations from @msheppar I have revised the fix. The more important change is that I have inverted the order in which the RawChannel.Events where registered, so that the ReadEvent (client side) is registered before the WriteEvent (client side). The suspicion here is that the handling of the WriteEvent is hogging the CPU (since there is always something to write) and the read event might not get registered until the test times out. That may - or may not be, the reason of the observed test failures, but comparing the logs of the tests that pass with the log of the tests that fail show that in the failing case the test is busy writing, and the read event is not being fired.
Another possibility is that some kind of failure happened to one of the threads, so the fixes also adds more logging and improve failure reporting so that we can better diagnose the issue if the test fails again.

Repeated testing has not seen the test fail again with those changes, but since the failure was happening very rarely in the first place that might not mean anything.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3517142365

From dfuchs at openjdk.org  Tue Nov 11 14:28:18 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Nov 2025 14:28:18 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v3]
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <Bx-IuDZHFGe-PV9zhwQCgiOqEiSD79sGATYLjmh6OIU=.b772af4f-4d2f-439b-9824-90c927e91ede@github.com>

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright dates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28178/files
  - new: https://git.openjdk.org/jdk/pull/28178/files/0ae487b8..e05864db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=01-02

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28178/head:pull/28178

PR: https://git.openjdk.org/jdk/pull/28178

From vyazici at openjdk.org  Tue Nov 11 15:06:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 11 Nov 2025 15:06:28 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v14]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <Asv3g5R1BqdPkW1jnAoKWt_3kog6tyK4TazAwEymOyE=.acc3680d-8478-4fa2-a2a4-c074bcff38a7@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Exclude disallowed timer cancellations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/802ce9de..0487a137

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=12-13

  Stats: 61 lines in 5 files changed: 40 ins; 6 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From vyazici at openjdk.org  Tue Nov 11 15:28:29 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 11 Nov 2025 15:28:29 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v15]
In-Reply-To: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
Message-ID: <TMzPExOcpIHXKkcmQKEWol0z4H7wNhB3KvHjpUdH80w=.e274894f-7e84-4d39-9d66-c28af09eaf40@github.com>

> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
> 
> ### Review guidelines
> 
> 1. Read _"the fix"_ in `MultiExchange`
> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Move `cancelTimerOnResponseBodySubscriberTermination` to `ExchangeImpl`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27469/files
  - new: https://git.openjdk.org/jdk/pull/27469/files/0487a137..1af53742

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=13-14

  Stats: 26 lines in 5 files changed: 12 ins; 11 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/27469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469

PR: https://git.openjdk.org/jdk/pull/27469

From dfuchs at openjdk.org  Tue Nov 11 19:26:02 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 11 Nov 2025 19:26:02 GMT
Subject: RFR: 8370024: HttpClient: QUIC congestion controller doesn't
 implement pacing [v2]
In-Reply-To: <agAYlA1R78gt2PfJ8DyhQTszllwL5h472sgXE0u5XeA=.a080b9d8-57ad-4dcd-b374-d5a106276398@github.com>
References: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
 <agAYlA1R78gt2PfJ8DyhQTszllwL5h472sgXE0u5XeA=.a080b9d8-57ad-4dcd-b374-d5a106276398@github.com>
Message-ID: <lpEhwkjpgcI9bKyCbrPk8FlMNmtyNqLiIxl2r8DmJ28=.e7dc87c2-d5a2-42dd-9951-a1828cd5383a@github.com>

On Thu, 6 Nov 2025 12:37:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Implement pacing for QUIC.
>> 
>> This is required by RFC 9002. Also, it improves the network utilization on links with long round-trip times.
>> 
>> The pacing algorithm itself was created based on the suggestions found in RFC 9002, and on the description of the Linux pacing algorithm.
>> 
>> Pacing is enabled when the round-trip time is less than twice the period at which the selector timeout fires. On Linux the selector timeout fires every millisecond, on Windows it's 15.6 milliseconds by default.
>> 
>> HttpClient tests came back clean.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary object allocation

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28156#pullrequestreview-3449611682

From vyazici at openjdk.org  Wed Nov 12 08:20:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 12 Nov 2025 08:20:04 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved
In-Reply-To: <VSslpKqIK0pOIzDt4JxUMzVdkT24C_IpkMfC1AlZbyE=.0f9eb358-aed5-4ff7-98d0-93d4eb8f169e@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <VSslpKqIK0pOIzDt4JxUMzVdkT24C_IpkMfC1AlZbyE=.0f9eb358-aed5-4ff7-98d0-93d4eb8f169e@github.com>
Message-ID: <uFW-JbqvFr4GmFla5HjjxQf_0BRCirsAVt6kejcTLX0=.703cc66a-e614-4136-9c6b-0f0d77f7f67c@github.com>

On Sat, 8 Nov 2025 15:51:19 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> bump

@SentryMan, thanks so much for the contribution, and the patience. ? This PR is on my radar. I cannot promise anything, but I will try to spare some review cycles for it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3520596937

From djelinski at openjdk.org  Wed Nov 12 08:59:49 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 08:59:49 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
Message-ID: <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>

On Tue, 11 Nov 2025 14:18:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - mark jdk.internal.net.http.Http2Connection as Closable
>  - reduce number of concurrent requests

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 904:

> 902:             final Http2TerminationCause tc = this.connTerminator.getTerminationCause();
> 903:             assert tc != null : "termination cause is null for a closed connection";
> 904:             return Optional.of(tc.getCloseCause());

Please remove this code block. The comment seems to imply that it fixes the race, but it doesn't.

I assume you verified that all callers of getTerminationException are properly synchronized, so that we don't leak resources if the method returns an empty optional while the connection is closed in another thread.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 1247:

> 1245:      */
> 1246:     final boolean isOpen() {
> 1247:         return this.connTerminator.terminationCause.get() == null && connection.channel().isOpen();

Can we ever observe a situation where channel is not open but termination cause is not set?

As far as I could tell, channel.isOpen only returns false after close() is called, and close() is only called from doTerminate after the termination cause is set. What am I missing?

src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 84:

> 82:      * such cases.
> 83:      */
> 84:     public abstract boolean isErroneousClose();

nit: can we use a different word here? "Erroneous close" feels vague here; would "is(Non)Graceful", "isAbrupt" or "hasErrorCode" capture the intent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517366540
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517371220
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517443404

From vyazici at openjdk.org  Wed Nov 12 11:22:28 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 12 Nov 2025 11:22:28 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
Message-ID: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>

On Tue, 11 Nov 2025 14:18:56 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - mark jdk.internal.net.http.Http2Connection as Closable
>  - reduce number of concurrent requests

I personally liked the clean-up of the state changes in `Http2Connection`, yet the change is non-trivial. I leave the judgement of that to reviewers more versed in `Http2Connection`.

src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 715:

> 713:                                 if (t != null) {
> 714:                                     if (!cached)
> 715:                                         c.close();

We remove the `if (!cached) c.close()` logic. Where do we restore this functionality? If not, why not?

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 234:

> 232:                 if (cancelled) {
> 233:                     if (debug.on()) {
> 234:                         debug.log("Not initiating idle connection close");

Suggestion:

                        debug.log("Connection is already cancelled, skipping idle connection close");

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 889:

> 887:      * If the connection hasn't yet been terminated then this method returns an empty Optional.
> 888:      */
> 889:     final Optional<IOException> getTerminationException() {

There is one place this method is used and it does `getTerminationException().orElse(null)`. I guess we can drop the `Optional` ceremony.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2056:

> 2054:         private void doTerminate() {
> 2055:             final Http2TerminationCause tc = terminationCause.get();
> 2056:             assert tc != null : "missing termination cause";

`doTerminate()` can receive the termination cause from `terminate()`, which would render these two lines redundant.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2071:

> 2069:                             peerVisibleReason.getBytes(UTF_8));
> 2070:                 }
> 2071:                 sendGoAway(goAway);

Do we need to take `sendGoAway()` failures into account?

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2076:

> 2074:                 Log.logError("Closing connection due to: {0}", tc);
> 2075:             } else {
> 2076:                 if (debug.on()) {

You can consider simplifying this as `else if (debug.on())`.

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2134:

> 2132:                 // that way when Http2Connection.isOpen() returns false in that situation, then this
> 2133:                 // getTerminationCause() will return a termination cause.
> 2134:                 terminate(Http2TerminationCause.forException(new IOException("channel is not open")));

Terminating the connection in a getter doesn't feel all right. Would you mind elaborating on the rationale, the absence of a better alternative, please?

src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 35:

> 33: 
> 34: /**
> 35:  * Termination cause for a {@linkplain Http2Connection HTTP/2 connection}

Suggestion:

 * Termination cause for an {@linkplain Http2Connection HTTP/2 connection}

src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 71:

> 69:      * Returns the IOException that is considered the cause of the connection termination.
> 70:      * Even a normal {@linkplain #isErroneousClose() non-erroneous} termination will have
> 71:      * a IOException associated with it, so this method will always return a non-null instance.

Suggestion:

     * Returns the {@link IOException} that is considered the cause of the connection termination.
     * Even a normal {@linkplain #isErroneousClose() non-erroneous} termination will have
     * an {@code IOException} associated with it, so this method will always return a non-null instance.

src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 144:

> 142:      */
> 143:     public static Http2TerminationCause idleTimedOut() {
> 144:         return new NoError("HTTP/2 connection idle timed out", "idle timed out");

Any particular reason this is not cached in `NoError.IDLE_TIMED_OUT` in a similar manner to `NoError.INSTANCE`? I could not see a place where its stack trace would be of value.

src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 176:

> 174:         } else {
> 175:             return new IOException(original);
> 176:         }

I presume we don't need to peel off any `CompletionException` and/or `ExecutionException`, right?

test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 102:

> 100:     private static Field openConnections; // Set<> jdk.internal.net.http.HttpClientImpl#openedConnections
> 101: 
> 102:     private static SSLContext sslContext;

Is SSL a necessity for this test? Put another way, does SSL play a role in the connection leakage?

test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 128:

> 126: 
> 127:     /*
> 128:      * Issues a burst of 100 HTTP/2 requests to the same server (host/port) and expects all of

`numRequests` is actually 20, not 100:

Suggestion:

     * Issues a burst of HTTP/2 requests to the same server (host/port) and expects all of

test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 134:

> 132:      */
> 133:     @Test
> 134:     void testOpenConnections() throws Exception {

Shall we also introduce following tests?

1. Verify secondary request bursts always reuse the pooled connection, and don't change the state of the pool. (Remember that, as reported in the associated ticket, the secondary bursts were causing the orphan connection pile up.)
2. Repeat all tests with a small idle timeout, say, 5s, and ensure that after 5s pool is completely emptied.

test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 195:

> 193:     // using reflection, return the jdk.internal.net.http.HttpClientImpl instance held
> 194:     // by the given client
> 195:     private static Object reflectHttpClientImplInstance(final HttpClient client) throws Exception {

Instead, you can use `Http3ConnectionAccess::impl` too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28233#pullrequestreview-3452322562
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517465442
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517499729
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517719632
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517572919
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517726876
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517606995
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517739033
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517552232
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517554830
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517550218
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517584896
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517824929
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517833332
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517866370
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517842337

From vyazici at openjdk.org  Wed Nov 12 11:22:30 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 12 Nov 2025 11:22:30 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>
Message-ID: <Mb_KZKkQ52_a4XunDYYH7YTsoN14KuNjHIAX5hF3tGo=.cfca3715-eafa-466e-82e2-fbf195393054@github.com>

On Wed, 12 Nov 2025 08:53:48 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 84:
> 
>> 82:      * such cases.
>> 83:      */
>> 84:     public abstract boolean isErroneousClose();
> 
> nit: can we use a different word here? "Erroneous close" feels vague here; would "is(Non)Graceful", "isAbrupt" or "hasErrorCode" capture the intent?

That that `erroneous close` has been used in several other contexts; in code, in comments, etc. If this gets updated, I'd appreciate other relevant occurrences get updated too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2517709873

From djelinski at openjdk.org  Wed Nov 12 12:32:04 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 12:32:04 GMT
Subject: RFR: 8370024: HttpClient: QUIC congestion controller doesn't
 implement pacing [v2]
In-Reply-To: <lpEhwkjpgcI9bKyCbrPk8FlMNmtyNqLiIxl2r8DmJ28=.e7dc87c2-d5a2-42dd-9951-a1828cd5383a@github.com>
References: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
 <agAYlA1R78gt2PfJ8DyhQTszllwL5h472sgXE0u5XeA=.a080b9d8-57ad-4dcd-b374-d5a106276398@github.com>
 <lpEhwkjpgcI9bKyCbrPk8FlMNmtyNqLiIxl2r8DmJ28=.e7dc87c2-d5a2-42dd-9951-a1828cd5383a@github.com>
Message-ID: <HOGmSEqLy_0pF6hKguMKY0uAE6iwNgt9mN1lit5zquQ=.22cb1fe5-46e7-4aea-b08d-381b5b8fd5d1@github.com>

On Tue, 11 Nov 2025 19:23:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary object allocation
>
> LGTM

Thanks @dfuch for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28156#issuecomment-3521696960

From djelinski at openjdk.org  Wed Nov 12 12:35:18 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 12:35:18 GMT
Subject: Integrated: 8370024: HttpClient: QUIC congestion controller doesn't
 implement pacing
In-Reply-To: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
References: <c3JuJX8nUhR2JM5_thYpeK_IWgLqmxRcw4Rz_BCkwT4=.3fb025a9-c8b3-4882-a8bd-4acaef401ce7@github.com>
Message-ID: <8nZLOj8xQn8v2sByhQL3BRcFVglxRSdYBC2NSAzboqw=.1047979e-b77c-451a-861b-97b900f83e75@github.com>

On Wed, 5 Nov 2025 18:04:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Implement pacing for QUIC.
> 
> This is required by RFC 9002. Also, it improves the network utilization on links with long round-trip times.
> 
> The pacing algorithm itself was created based on the suggestions found in RFC 9002, and on the description of the Linux pacing algorithm.
> 
> Pacing is enabled when the round-trip time is less than twice the period at which the selector timeout fires. On Linux the selector timeout fires every millisecond, on Windows it's 15.6 milliseconds by default.
> 
> HttpClient tests came back clean.

This pull request has now been integrated.

Changeset: 1f1f7bb4
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f1f7bb44842fac966bd8f16cc6cfeee0ea972f6
Stats:     675 lines in 7 files changed: 659 ins; 2 del; 14 mod

8370024: HttpClient: QUIC congestion controller doesn't implement pacing

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28156

From dfuchs at openjdk.org  Wed Nov 12 12:42:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Nov 2025 12:42:28 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>
Message-ID: <_HNEdyey9YHsBC0OO1NbgNufOAxyoQuiJq6f73bDaHc=.5cf0f945-7611-4e17-9ef4-9ab189dfccce@github.com>

On Wed, 12 Nov 2025 08:28:46 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 1247:
> 
>> 1245:      */
>> 1246:     final boolean isOpen() {
>> 1247:         return this.connTerminator.terminationCause.get() == null && connection.channel().isOpen();
> 
> Can we ever observe a situation where channel is not open but termination cause is not set?
> 
> As far as I could tell, channel.isOpen only returns false after close() is called, and close() is only called from doTerminate after the termination cause is set. What am I missing?

A channel can be closed by the peer. So it may be closed even if close() has not been called.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2518154884

From djelinski at openjdk.org  Wed Nov 12 12:46:18 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 12:46:18 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v2]
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <1HxhvT2juG4K8f3hAuf07GyVNfzHmzyMH181MFlJFKU=.9509fa69-b28c-4875-924e-bfc1f6f14525@github.com>

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28195/files
  - new: https://git.openjdk.org/jdk/pull/28195/files/b95950f2..b95950f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28195/head:pull/28195

PR: https://git.openjdk.org/jdk/pull/28195

From dfuchs at openjdk.org  Wed Nov 12 12:52:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Nov 2025 12:52:22 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <BOAGW5A4DegAdannhex4hsyf9hhkzHv_-ylWEO7PRs4=.4c85207d-39be-4496-870b-efcf1c343275@github.com>

On Wed, 12 Nov 2025 09:00:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> src/java.net.http/share/classes/jdk/internal/net/http/Exchange.java line 715:
> 
>> 713:                                 if (t != null) {
>> 714:                                     if (!cached)
>> 715:                                         c.close();
> 
> We remove the `if (!cached) c.close()` logic. Where do we restore this functionality? If not, why not?

If the terminationException is not null the connection is already closed (or being closed by another thread) so there's no need to call close() again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2518187028

From djelinski at openjdk.org  Wed Nov 12 15:13:18 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 15:13:18 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Update test comments
 - Convert CubicTest to JUnit
 - Merge declaration and assignment
 - More aggressive target growth
 - Merge remote-tracking branch 'origin/master' into quic-cubic
 - Make classes final
 - Rename system property to internal
 - Add a system property to select congestion controller
 - Implement fast convergence
 - Add comments
 - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89

-------------

Changes: https://git.openjdk.org/jdk/pull/28195/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=02
  Stats: 970 lines in 6 files changed: 709 ins; 254 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28195/head:pull/28195

PR: https://git.openjdk.org/jdk/pull/28195

From djelinski at openjdk.org  Wed Nov 12 15:24:33 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 15:24:33 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
Message-ID: <BJTXy89drr2gzIhPYC6MK1QJ94U4_eJMuWiISk48vsU=.3e7c5de0-90a2-45fc-b66e-17674fa11066@github.com>

On Wed, 12 Nov 2025 15:13:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Update test comments
>  - Convert CubicTest to JUnit
>  - Merge declaration and assignment
>  - More aggressive target growth
>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>  - Make classes final
>  - Rename system property to internal
>  - Add a system property to select congestion controller
>  - Implement fast convergence
>  - Add comments
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89

Thanks @AlanBateman @vy for the reviews.

The property was not meant to be exposed; IMO CUBIC is superior to Reno in all aspects that matter. I renamed it to include `internal`.

We will probably need to revisit the configuration if and when we implement BBR, but we aren't quite there yet.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28195#pullrequestreview-3453025390

From djelinski at openjdk.org  Wed Nov 12 15:24:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 15:24:43 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v2]
In-Reply-To: <PO3Qf37aLMxE5wZva5VgmXgefcDg5Yo2Mc8eumoXOLM=.d89bd085-95a7-4b89-b0b1-d9543d4ad2d7@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <PO3Qf37aLMxE5wZva5VgmXgefcDg5Yo2Mc8eumoXOLM=.d89bd085-95a7-4b89-b0b1-d9543d4ad2d7@github.com>
Message-ID: <_EXGbQ-I9MvGC4VJhjwLQS2zMALYl7M02Ai4ZG839oo=.445eaf03-1143-4e8f-928f-a939a05feba0@github.com>

On Fri, 7 Nov 2025 17:24:11 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
>> 
>>  - Add a system property to select congestion controller
>>  - Implement fast convergence
>>  - Add comments
>>  - Update test
>>  - Revert: more aggressive window increases
>>  - Test the cubic curve
>>  - Use custom timeline for testing
>>  - Documentation updates
>>  - Cubic tests, more aggressive Reno window increase
>>  - Log K in milliseconds
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/5191d720...b95950f2
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicConnectionImpl.java line 371:
> 
>> 369:     private static QuicCongestionController createCongestionController
>> 370:             (String dbgTag, QuicRttEstimator rttEstimator) {
>> 371:         String algo = System.getProperty("jdk.httpclient.quic.congestionController", "cubic");
> 
> Can we keep this internal? That is, can we use `jdk.internal.httpclient.quic.congestionController` instead?

Yes, that was my intention, I forgot we use the `internal` segment for internal properties. Updated.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 41:
> 
>> 39:  *       RFC 9438: CUBIC for Fast and Long-Distance Networks
>> 40:  */
>> 41: public class QuicCubicCongestionController extends QuicBaseCongestionController {
> 
> I guess this can be `final`.

Updated.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 62:
> 
>> 60:     public QuicCubicCongestionController(String dbgTag, QuicRttEstimator rttEstimator) {
>> 61:         super(dbgTag, rttEstimator);
>> 62:         this.rttEstimator = rttEstimator;
> 
> Can we make `rttEstimator` a `protected` field of `QuicBaseCongestionController`?

We could. The Reno congestion controller doesn't use the estimator other than passing it to the pacer, so I decided not to include it in the base class.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 112:
> 
>> 110:     protected boolean congestionAvoidanceAcked(int packetBytes, Deadline sentTime) {
>> 111:         boolean isAppLimited;
>> 112:         isAppLimited = sentTime.isAfter(lastFullWindow);
> 
> Suggestion:
> 
>         boolean isAppLimited = sentTime.isAfter(lastFullWindow);

Updated.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 122:
> 
>> 120:             // target = Wcubic(t)
>> 121:             // this is less aggressive than RFC 9438, which uses target=Wcubic(t+RTT),
>> 122:             // but seems to work well enough
> 
> Shall we also document why we deviate from the RFC?

We can do better than that and actually implement the equation from the RFC. Updated.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicRenoCongestionController.java line 40:
> 
>> 38:  *      RFC 9002: QUIC Loss Detection and Congestion Control
>> 39:  */
>> 40: class QuicRenoCongestionController extends QuicBaseCongestionController {
> 
> I guess thins can be `final` and consequently `protected` modifier can be removed from the implemented methods.

Changed the class to final. The protected modifier is still needed on overridden methods.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicRenoCongestionController.java line 47:
> 
>> 45:     protected boolean congestionAvoidanceAcked(int packetBytes, Deadline sentTime) {
>> 46:         boolean isAppLimited;
>> 47:         isAppLimited = congestionWindow > maxBytesInFlight + 2L * maxDatagramSize;
> 
> Suggestion:
> 
>         boolean isAppLimited = congestionWindow > maxBytesInFlight + 2L * maxDatagramSize;
> 
> 
> @djelinski, I see you verbatim copied these lines ? which is fine, and makes things easier to review. Nevertheless, I want to double-check: do we need to guard against any arithmetic overflows here?

Suggestion applied.

MaxBytesInFlight is limited by the amount of available memory, and soft-limited to 16M (see `MAX_BYTES_IN_FLIGHT` in base congestion controller). While it can cross the limit briefly, I don't expect it to get anywhere near the arithmetic limits.

> test/jdk/java/net/httpclient/quic/CubicTest.java line 42:
> 
>> 40: /*
>> 41:  * @test
>> 42:  * @run testng/othervm -Djdk.httpclient.HttpClient.log=trace,quic:cc CubicTest
> 
> Shall we use JUnit instead?

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2517986292
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2517986863
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2518734798
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2518006013
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2518442424
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2518452038
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2518485342
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2518698935

From dfuchs at openjdk.org  Wed Nov 12 16:43:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Nov 2025 16:43:50 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT
Message-ID: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>

The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).

The proposed change makes sure we use Locale.ROOT to format the message.

-------------

Commit messages:
 - 8371722: java/net/httpclient/BufferSizePropertyClampTest.java should use Locale.ROOT

Changes: https://git.openjdk.org/jdk/pull/28270/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28270&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371722
  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28270/head:pull/28270

PR: https://git.openjdk.org/jdk/pull/28270

From dfuchs at openjdk.org  Wed Nov 12 18:03:33 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 12 Nov 2025 18:03:33 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
Message-ID: <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>

> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
> 
> The proposed change makes sure we use Locale.ROOT to format the message.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Fix the fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28270/files
  - new: https://git.openjdk.org/jdk/pull/28270/files/2c9acb4b..e2f803fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28270&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28270&range=00-01

  Stats: 11 lines in 1 file changed: 7 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28270.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28270/head:pull/28270

PR: https://git.openjdk.org/jdk/pull/28270

From djelinski at openjdk.org  Wed Nov 12 19:45:20 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 12 Nov 2025 19:45:20 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
 <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
Message-ID: <SCrbJ2ObnSUIrPcIfCklg6HM45S0p46lPqaPAA8S8vI=.be75f2a6-7593-41ac-92e1-4b655c28cb6f@github.com>

On Wed, 12 Nov 2025 18:03:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
>> 
>> The proposed change makes sure we use Locale.ROOT to format the message.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the fix

I verified that this fixed the test failures on my Windows machine.

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28270#pullrequestreview-3455145226

From jpai at openjdk.org  Thu Nov 13 04:19:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Nov 2025 04:19:01 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
 <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
Message-ID: <am3c5S1_p6HNhCn3IccigwP4xecKhHo0mOr_CMmHnAY=.10491cbf-53ae-4da3-8fd1-47ab72d9608f@github.com>

On Wed, 12 Nov 2025 18:03:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
>> 
>> The proposed change makes sure we use Locale.ROOT to format the message.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the fix

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28270#pullrequestreview-3457231632

From vyazici at openjdk.org  Thu Nov 13 06:10:04 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 13 Nov 2025 06:10:04 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
 <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
Message-ID: <4OOELMqGm_ZQk4hYPS5BOew2pjVn7UGOtJSVwrz9tAM=.f2e9cf11-0096-4109-a656-0cc3667f67a2@github.com>

On Wed, 12 Nov 2025 18:03:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
>> 
>> The proposed change makes sure we use Locale.ROOT to format the message.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the fix

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28270#pullrequestreview-3457678366

From vyazici at openjdk.org  Thu Nov 13 06:15:03 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 13 Nov 2025 06:15:03 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
 <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
Message-ID: <NHn_5rt97Up3SGUj5V5apQbrqfTQY5s0hXYj7qe3vCQ=.9c9d6e34-7123-4f7d-9ad0-6f8d3e796a18@github.com>

On Wed, 12 Nov 2025 18:03:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
>> 
>> The proposed change makes sure we use Locale.ROOT to format the message.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the fix

test/jdk/java/net/httpclient/BufferSizePropertyClampTest.java line 73:

> 71: 
> 72:     private static final String EXPECTED_MSG =
> 73:             "ERROR: Property value for jdk.httpclient.bufsize={0} not in [1..16,384]: using default=16,384";

Doesn't this have an assumption on the formatting of 1 and 16384, and hence, suffers from the same short-coming this fix is aiming to solve? That is, the original `Utils::getIntegerNetProperty` message is as follows:


"Property value for {0}={1} not in [{2}..{3}]: using default={4}"


Shouldn't we be using this message verbatim instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28270#discussion_r2521731243

From vyazici at openjdk.org  Thu Nov 13 06:32:10 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 13 Nov 2025 06:32:10 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
Message-ID: <MsY5PfzLyrhjIYCdVDUfposeBZBu5sdOXjxZ0VEMpic=.0bacd801-6809-46f1-80c9-0c8501f00b69@github.com>

On Wed, 12 Nov 2025 15:13:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Update test comments
>  - Convert CubicTest to JUnit
>  - Merge declaration and assignment
>  - More aggressive target growth
>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>  - Make classes final
>  - Rename system property to internal
>  - Add a system property to select congestion controller
>  - Implement fast convergence
>  - Add comments
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicBaseCongestionController.java line 58:

> 56:     private static final int MAX_BYTES_IN_FLIGHT = Math.clamp(
> 57:             Utils.getLongProperty("jdk.httpclient.quic.maxBytesInFlight", 1 << 24),
> 58:             1 << 14, 1 << 24);

Utils#getIntegerNetProperty(String property, int min, int max, int defaultValue, boolean log)

does clamping, and supports logging on invalid input. AFAICS, `Utils::getLongProperty` was introduced with HTTP/3, yet lacks the versatility of `getIntegerNetProperty`. @dfuch, is this a room for improvement, or is it not worth the code churn?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2521788316

From dfuchs at openjdk.org  Thu Nov 13 10:46:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 10:46:28 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
 <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
Message-ID: <U4JdfecYhY-pw4Ue2sC9dBhBNZtrbFlhG95emby2oY0=.62e89112-a5dc-4685-9e9e-c9f7e0404f1a@github.com>

On Wed, 12 Nov 2025 18:03:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
>> 
>> The proposed change makes sure we use Locale.ROOT to format the message.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the fix

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28270#issuecomment-3527153697

From dfuchs at openjdk.org  Thu Nov 13 10:48:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 10:48:34 GMT
Subject: Integrated: 8371722:
 java/net/httpclient/BufferSizePropertyClampTest.java should use Locale.ROOT
In-Reply-To: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
Message-ID: <PxqaTmbYAIoI3s-Aa0tiAjE-tSOS2pYikW6fnPCxPkE=.2e1a35c9-0b24-405e-9383-e6db6f6218e0@github.com>

On Wed, 12 Nov 2025 16:35:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The test verifies that the expected message is logged by the jdk.httpclient.HttpClient logger. However it fails when run in e.g. Polish Locale because it expects 16,384 and finds 16 384 (with a non breaking space).
> 
> The proposed change makes sure we use Locale.ROOT to format the message.

This pull request has now been integrated.

Changeset: 48c59faf
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48c59faf58a4d7b7ec9d6824a5cbc9a55888ce72
Stats:     13 lines in 1 file changed: 8 ins; 2 del; 3 mod

8371722: java/net/httpclient/BufferSizePropertyClampTest.java should use Locale.ROOT

Reviewed-by: djelinski, jpai, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/28270

From dfuchs at openjdk.org  Thu Nov 13 10:46:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 10:46:31 GMT
Subject: RFR: 8371722: java/net/httpclient/BufferSizePropertyClampTest.java
 should use Locale.ROOT [v2]
In-Reply-To: <NHn_5rt97Up3SGUj5V5apQbrqfTQY5s0hXYj7qe3vCQ=.9c9d6e34-7123-4f7d-9ad0-6f8d3e796a18@github.com>
References: <rCA0epge8DabYbl_T4FfsMJNRabJHP0f4PEPPOcskY4=.7119ed88-39ad-4734-be5d-49b271ecdd8b@github.com>
 <jn9ssmBWax0gRvwUy6SOmAcWmW9eh26Y_INrRJYyq0I=.8be630dc-f12a-4d3f-977a-249cc33549da@github.com>
 <NHn_5rt97Up3SGUj5V5apQbrqfTQY5s0hXYj7qe3vCQ=.9c9d6e34-7123-4f7d-9ad0-6f8d3e796a18@github.com>
Message-ID: <8Q_pAxUmg3QWDZmk-IJcoBSB41Cy3ieafzPKBV1TtMY=.b9ea28dc-bc3e-46c5-bd5c-455bd8248a27@github.com>

On Thu, 13 Nov 2025 06:12:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the fix
>
> test/jdk/java/net/httpclient/BufferSizePropertyClampTest.java line 73:
> 
>> 71: 
>> 72:     private static final String EXPECTED_MSG =
>> 73:             "ERROR: Property value for jdk.httpclient.bufsize={0} not in [1..16,384]: using default=16,384";
> 
> Doesn't this have an assumption on the formatting of 1 and 16384, and hence, suffers from the same short-coming this fix is aiming to solve? That is, the original `Utils::getIntegerNetProperty` message is as follows:
> 
> 
> "Property value for {0}={1} not in [{2}..{3}]: using default={4}"
> 
> 
> Shouldn't we be using this message verbatim instead?

Yes and no. We're now using Locale.ROOT to do the formating so we know how it will be formatted (and can make the assumption).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28270#discussion_r2522901042

From dfuchs at openjdk.org  Thu Nov 13 13:07:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 13:07:47 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v4]
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <r6GjS0O62c-7Lh_t6MhJz4UzHof_2yIVAiZN25P9l0I=.09d509de-9c6b-4d2e-a554-e8d8cef34034@github.com>

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Review feedback: the issue is the logic in byteArrayOfSize
 - Merge branch 'master' into RawChannel-8371366
 - Fix copyright dates
 - Review feedback: increasing the timeout might not help
 - Merge branch 'master' into RawChannel-8371366
 - 8371366: java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in jtreg timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28178/files
  - new: https://git.openjdk.org/jdk/pull/28178/files/e05864db..18203dab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=02-03

  Stats: 13718 lines in 142 files changed: 9233 ins; 3636 del; 849 mod
  Patch: https://git.openjdk.org/jdk/pull/28178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28178/head:pull/28178

PR: https://git.openjdk.org/jdk/pull/28178

From dfuchs at openjdk.org  Thu Nov 13 13:14:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 13:14:25 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v5]
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <Rvuq8n77QziGOUAn6g3sOjYdX6ILEsAlcIndPAEFEsQ=.cc185275-c617-4505-8522-744c417ff236@github.com>

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28178/files
  - new: https://git.openjdk.org/jdk/pull/28178/files/18203dab..f9b48b19

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28178/head:pull/28178

PR: https://git.openjdk.org/jdk/pull/28178

From dfuchs at openjdk.org  Thu Nov 13 13:14:27 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 13:14:27 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v3]
In-Reply-To: <Bx-IuDZHFGe-PV9zhwQCgiOqEiSD79sGATYLjmh6OIU=.b772af4f-4d2f-439b-9824-90c927e91ede@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
 <Bx-IuDZHFGe-PV9zhwQCgiOqEiSD79sGATYLjmh6OIU=.b772af4f-4d2f-439b-9824-90c927e91ede@github.com>
Message-ID: <GqJDYJ5wCDUBHj4KOzJLKxXfiZcrCYQ5_ZevN1-CZpM=.55542e96-2b54-4afa-81cc-9ff22e6cfbde@github.com>

On Tue, 11 Nov 2025 14:28:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
>> 
>> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright dates

@djelinski nailed the issue: the method `byteArrayOfSize(1024);` may return new byte[0], and if that happens the server will write nothing and the ReadEvent will never be fired. The server will then be blocked waiting on readStalled.await().

This is what happens in the failing test:

Thread[#30,Thread-3,5,MainThreadGroup]: Server wrote total 491: awaiting initialReadStall
Thread[#30,Thread-3,5,MainThreadGroup]: Server wrote total 491: awaiting readStall

the second write was of 0 bytes - since the total number of bytes did not change

I have adapted the fix accordingly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28178#issuecomment-3527741220

From djelinski at openjdk.org  Thu Nov 13 13:18:03 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Nov 2025 13:18:03 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v5]
In-Reply-To: <Rvuq8n77QziGOUAn6g3sOjYdX6ILEsAlcIndPAEFEsQ=.cc185275-c617-4505-8522-744c417ff236@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
 <Rvuq8n77QziGOUAn6g3sOjYdX6ILEsAlcIndPAEFEsQ=.cc185275-c617-4505-8522-744c417ff236@github.com>
Message-ID: <bRtwfZ0sYquKeBMVgbs3DOnIqGVmZ4o59SnAnsrnSrg=.83d09be3-5d3f-4795-a20e-f327fa2759d8@github.com>

On Thu, 13 Nov 2025 13:14:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
>> 
>> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Marked as reviewed by djelinski (Reviewer).

test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/RawChannelTest.java line 166:

> 164:                         writeStall.countDown(); // signal send buffer is full
> 165:                     } catch (IOException e) {
> 166:                         print("OP_RIGHT failed: " + e);

Suggestion:

                        print("OP_WRITE failed: " + e);

-------------

PR Review: https://git.openjdk.org/jdk/pull/28178#pullrequestreview-3459737196
PR Review Comment: https://git.openjdk.org/jdk/pull/28178#discussion_r2523422595

From djelinski at openjdk.org  Thu Nov 13 13:25:10 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Nov 2025 13:25:10 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <MsY5PfzLyrhjIYCdVDUfposeBZBu5sdOXjxZ0VEMpic=.0bacd801-6809-46f1-80c9-0c8501f00b69@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <MsY5PfzLyrhjIYCdVDUfposeBZBu5sdOXjxZ0VEMpic=.0bacd801-6809-46f1-80c9-0c8501f00b69@github.com>
Message-ID: <HtvQmh3igSSyzfCQSjbCqfhLjQ3QbS8PZrdPYklhlkQ=.17a72a16-579b-4057-89ea-d2869d23877c@github.com>

On Thu, 13 Nov 2025 06:29:15 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Update test comments
>>  - Convert CubicTest to JUnit
>>  - Merge declaration and assignment
>>  - More aggressive target growth
>>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>>  - Make classes final
>>  - Rename system property to internal
>>  - Add a system property to select congestion controller
>>  - Implement fast convergence
>>  - Add comments
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicBaseCongestionController.java line 58:
> 
>> 56:     private static final int MAX_BYTES_IN_FLIGHT = Math.clamp(
>> 57:             Utils.getLongProperty("jdk.httpclient.quic.maxBytesInFlight", 1 << 24),
>> 58:             1 << 14, 1 << 24);
> 
> Utils#getIntegerNetProperty(String property, int min, int max, int defaultValue, boolean log)
> 
> does clamping, and supports logging on invalid input. AFAICS, `Utils::getLongProperty` was introduced with HTTP/3, yet lacks the versatility of `getIntegerNetProperty`. @dfuch, is this a room for improvement, or is it not worth the code churn?

I think we could use clamping overloads of the getXXXProperty methods. There are quite a few places where they would be useful. But let's not do that in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2523451111

From dfuchs at openjdk.org  Thu Nov 13 13:38:25 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 13:38:25 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v6]
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <uWBOnf6WDm5riIKnLhQtqSq3vjyNxQDh4gIrkciaAYc=.1cd41443-ff82-463f-9643-24c6d6d272c9@github.com>

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/RawChannelTest.java
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28178/files
  - new: https://git.openjdk.org/jdk/pull/28178/files/f9b48b19..5547d88b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28178&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28178/head:pull/28178

PR: https://git.openjdk.org/jdk/pull/28178

From djelinski at openjdk.org  Thu Nov 13 13:38:27 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Nov 2025 13:38:27 GMT
Subject: RFR: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout [v6]
In-Reply-To: <uWBOnf6WDm5riIKnLhQtqSq3vjyNxQDh4gIrkciaAYc=.1cd41443-ff82-463f-9643-24c6d6d272c9@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
 <uWBOnf6WDm5riIKnLhQtqSq3vjyNxQDh4gIrkciaAYc=.1cd41443-ff82-463f-9643-24c6d6d272c9@github.com>
Message-ID: <H_bpIY1KVx_-Bh4oQL3K8uefcgCs3be2sPbhFTg-hPU=.43c6b5b7-3f22-435b-9a02-cbcab85fb8f6@github.com>

On Thu, 13 Nov 2025 13:34:54 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
>> 
>> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/net/httpclient/whitebox/java.net.http/jdk/internal/net/http/RawChannelTest.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28178#pullrequestreview-3459816188

From djelinski at openjdk.org  Thu Nov 13 14:37:43 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 13 Nov 2025 14:37:43 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
Message-ID: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>

On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed line wrapping

Can you convert or remove the `IPAddressDNSIdentities` test as well?

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36:

> 34:  * @library /test/lib
> 35:  * @modules java.base/sun.security.x509 java.base/sun.security.util
> 36:  * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA

as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default?

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 39:

> 37: 
> 38: /*
> 39:  * This test depends on binary keystore, crisubn.jks and trusted.jks. Because

Peease remove the crisubn.jks and trusted.jks files from this directory, they aren't used anywhere else.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 157:

> 155:         ks.setCertificateEntry("Trusted Cert", trustedCert);
> 156: 
> 157:         Certificate[] chain = new Certificate[] {serverCert, trustedCert};

(probably preexisting) you can remove the trusted cert from the chain; real servers usually don't send it.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 190:

> 188:     void doClientSide() throws Exception {
> 189: 
> 190:         if (!serverReady.await(SERVER_WAIT_SECS, TimeUnit.SECONDS)) {

I'd remove the time limit, it only causes trouble when people increase test concurrency and timeout factors.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1:

> 1: /*

This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one?

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:

> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
> 103:                 .addBasicConstraintsExt(false, false, -1)
> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))

I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 119:

> 117:                         CertificateBuilder.KeyUsage.NONREPUDIATION,
> 118:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
> 119:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))

Same here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3459883168
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523546617
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523539070
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523561169
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523555451
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523677717
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523705701
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2523706426

From duke at openjdk.org  Thu Nov 13 15:05:49 2025
From: duke at openjdk.org (EunHyunsu)
Date: Thu, 13 Nov 2025 15:05:49 GMT
Subject: RFR: 8328894: HttpResponse.body() returns null with https target
 and failed proxy authentication
In-Reply-To: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>
References: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>
Message-ID: <sv7lLSOAUpFYc2jnmkuKK6qWsjodNxCTBxQW0853Otg=.c110ef7f-a09b-4641-a42a-b794e81900c2@github.com>

On Tue, 11 Nov 2025 11:31:22 GMT, EunHyunsu <duke at openjdk.org> wrote:

> ### Summary
>   This patch addresses the issue where `HttpResponse.body()` returns `null` for 407 responses when using HTTPS through a proxy, while HTTP requests correctly return the response body.
> 
>   ### Problem
>   When an HTTPS request receives a 407 Proxy Authentication Required response, the response body is discarded during CONNECT tunnel establishment. This is inconsistent with HTTP behavior where the body is properly returned.
> 
>   **Root cause:**
>   - HTTPS uses `MultiExchange<Void>` for CONNECT requests
>   - The body is explicitly ignored via `ignoreBody()` on 407 responses
>   - No mechanism exists to preserve the body for later retrieval
> 
>   ### Proposed Solution
>   I propose the following changes to preserve and return the 407 response body:
> 
>   1. **PlainTunnelingConnection.java**: Change `MultiExchange<Void>` to `MultiExchange<byte[]>` and read the body on 407 responses instead of ignoring it
> 
>   2. **ProxyAuthenticationRequired.java**: Add `proxyResponseBody` field to carry the body bytes through the exception
> 
>   3. **Exchange.java**: Cache both the proxy response and body, then return them when the application calls `body()`
> 
>   ### Testing
>   Added comprehensive test (`ProxyAuthHttpTest.java`) covering:
>   - Basic HTTP and HTTPS 407 responses
>   - Multiple `BodyHandler` types: `ofString()`, `ofByteArray()`, `ofInputStream()`, `ofLines()`
>   - Response headers validation
> 
>   **Test results**: 38/38 passed
> 
>   ### Notes
>   - This change only affects 407 responses; all other flows remain unchanged
>   - The cached body is cleared after first use to prevent reuse
>   - No changes to public APIs; internal implementation only
> 
>   I'd appreciate any feedback on this approach. If there's a better way to handle this, I'm happy to revise.

Gentle ping ? just checking if anyone could take a look when time permits.
Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28232#issuecomment-3528218442

From dfuchs at openjdk.org  Thu Nov 13 17:00:13 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 17:00:13 GMT
Subject: RFR: 8328894: HttpResponse.body() returns null with https target
 and failed proxy authentication
In-Reply-To: <sv7lLSOAUpFYc2jnmkuKK6qWsjodNxCTBxQW0853Otg=.c110ef7f-a09b-4641-a42a-b794e81900c2@github.com>
References: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>
 <sv7lLSOAUpFYc2jnmkuKK6qWsjodNxCTBxQW0853Otg=.c110ef7f-a09b-4641-a42a-b794e81900c2@github.com>
Message-ID: <YVWxou3OhH1ywQKkSjsJLhjVufgkhEY25Xuy4NULCyc=.a01756c4-af9c-4d75-9638-9503c81536cf@github.com>

On Thu, 13 Nov 2025 15:02:19 GMT, EunHyunsu <duke at openjdk.org> wrote:

> Gentle ping ? just checking if anyone could take a look when time permits.
> Thank you!

Hello @ehs208 this will take some time to review. I haven't reviewed in details but I don't specially like the forced conversion to byte[] which forces reading the whole response in memory. If there's no way around that we should probably set a limit on the number of bytes we're prepared to accept. For these reasons I'd rather delay this fix until after the RDP 1 fork.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28232#issuecomment-3528776954

From dfuchs at openjdk.org  Thu Nov 13 17:35:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Nov 2025 17:35:40 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
Message-ID: <qYNw6SPKGW8XZrEmdLgzRI2mV_bsaywORxRSFmJjkNs=.a423a53d-2240-4d20-8d62-19e233a1a4fa@github.com>

On Thu, 13 Nov 2025 17:04:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove duplicate export of jdk.internal.util to java.net.http.

LGTM.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28301#pullrequestreview-3460918328

From rriggs at openjdk.org  Thu Nov 13 18:38:21 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 18:38:21 GMT
Subject: RFR: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <edzrwTO_9sNnceHFqLdDXW1fJT0vT94MmD3KnTDpTbQ=.8658fbc7-7478-48ba-9635-35210b7ca3da@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
 <edzrwTO_9sNnceHFqLdDXW1fJT0vT94MmD3KnTDpTbQ=.8658fbc7-7478-48ba-9635-35210b7ca3da@github.com>
Message-ID: <9c0IkPnDoQ0SqIbliRa08xnd1Q3oIAfzpupO1FMrxnQ=.b8098797-ed59-4237-a68f-02aea33741a6@github.com>

On Thu, 13 Nov 2025 17:14:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do you mind digging into if we have a javac issue or is the GenModuleInfoSource tool in the build masking this as it generates the module-info.java that is compiled.

It appears that GenModuleInfoSource does not check for duplicates. 
Targets are accumulated to a Set<String> and duplicates are ignored.
Created [JDK-8371851](https://bugs.openjdk.org/browse/JDK-8371851) to track any followup.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28301#issuecomment-3529166483

From rriggs at openjdk.org  Thu Nov 13 19:11:16 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Nov 2025 19:11:16 GMT
Subject: Integrated: 8371821: Duplicate export of jdk.internal.util to
 java.net.http
In-Reply-To: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
References: <2_lUFK-g3QQP2VQxb8kqrSehyCNPzagaFpHSvYTdFbw=.20a2035c-dc78-4a06-acd8-65e9096222d6@github.com>
Message-ID: <M-FZYp8xivTSEjXwb5LrIK6_wEBEHIbUG-2fjM2wBiw=.ecd56cbf-81ad-44c0-ad3b-816ea4f3baa3@github.com>

On Thu, 13 Nov 2025 17:04:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove duplicate export of jdk.internal.util to java.net.http.

This pull request has now been integrated.

Changeset: 6322aaba
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6322aaba63b235cb6c73d23a932210af318404ec
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8371821: Duplicate export of jdk.internal.util to java.net.http

Reviewed-by: naoto, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28301

From mail at laeubi-soft.de  Fri Nov 14 09:06:25 2025
From: mail at laeubi-soft.de (=?UTF-8?Q?Christoph_L=C3=A4ubrich?=)
Date: Fri, 14 Nov 2025 10:06:25 +0100
Subject: [JDK-8361305] Bug can be closed
Message-ID: <f730d2b2-8196-4c12-a885-5d7e97948688@laeubi-soft.de>

As it seems there is no easy way to comment on a JDK bug:

After testing what was written in the comment of

https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8361305

I think the writer is correct, everything works as expected/specified 
here. I wrongly assumed ws:// would do something different but can 
confirm that using ws:// instead of http works. One might argue that 
http can be an alias to ws:// but I'm not sure its worth a change here 
as it is only a little inconvenience to have to use two different URI if 
the endpoint supports both http+ws

From daniel.fuchs at oracle.com  Fri Nov 14 09:16:14 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 14 Nov 2025 09:16:14 +0000
Subject: [JDK-8361305] Bug can be closed
In-Reply-To: <f730d2b2-8196-4c12-a885-5d7e97948688@laeubi-soft.de>
References: <f730d2b2-8196-4c12-a885-5d7e97948688@laeubi-soft.de>
Message-ID: <da50e4de-e585-4038-a496-62db24ea7b32@oracle.com>

Hi Christoph,

Thanks for confirming that this is not an issue.
I really appreciate that.

I have closed https://bugs.openjdk.org/browse/JDK-8361305 now.

MfG,

-- daniel


On 14/11/2025 09:06, Christoph L?ubrich wrote:
> As it seems there is no easy way to comment on a JDK bug:
> 
> After testing what was written in the comment of
> 
> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8361305
> 
> I think the writer is correct, everything works as expected/specified 
> here. I wrongly assumed ws:// would do something different but can 
> confirm that using ws:// instead of http works. One might argue that 
> http can be an alias to ws:// but I'm not sure its worth a change here 
> as it is only a little inconvenience to have to use two different URI if 
> the endpoint supports both http+ws


From hashjangcyber at gmail.com  Thu Nov 13 11:07:43 2025
From: hashjangcyber at gmail.com (hashjangcyber at gmail.com)
Date: Thu, 13 Nov 2025 19:07:43 +0800
Subject: Proposal of introducing new JFR events for DNS lookups
Message-ID: <80e7ca0d-640b-48f3-8709-f59b91d4756c@Spark>

Hello,
I would like to start a discussion on introducing new JFR events for DNS lookups. While many lookups are DNS in cloud-native environments, the JDK uses the configured name service, so the event naming and semantics should not imply DNS-only behavior. I?m seeking feedback on scope, naming, and payload fields.
Motivation


? High-frequency, latency-sensitive lookups are critical for service discovery.

? Current gaps:
    ? Cannot distinguish cache hits vs. network lookups

    ? Hard to trace lookup latency and diagnose timeouts/failures

    ? Concurrent libraries may cause redundant lookups

? Value:
    ? End-to-end observability: lookup ? socket connect ? data transfer

    ? Troubleshooting: identify timeouts, resolution failures

    ? Performance: evaluate cache policies, detect hotspot names

    ? Security: audit external domains accessed


Proposed event (initial draft)
Event name:?jdk.DnsLookup
When:?Emitted around DNS hostname resolution call boundaries,?including:


? Actual network DNS queries (when cache is disabled or cache miss occurs)

? Cache hits (when result is retrieved from DNS cache)

? Stale data usage (when expired but still valid cached data is used)

? Background DNS cache refresh operations


Key fields (feedback welcome):


? host?(String): The hostname being resolved

? result?(String): Comma-separated list of resolved IP addresses, or error message if lookup failed

? success?(boolean): Whether the DNS lookup was successful

? cached?(boolean): Whether the result was retrieved from cache (true) or from actual DNS network query (false). This helps distinguish between three use cases:
    ? Actual network queries (cached=false) - represents real DNS network traffic

    ? Cache hits (cached=true, stale=false) - repeated lookups using fresh cached data

    ? Stale data usage (cached=true, stale=true) - application continues with expired but still valid cached data when DNS refresh fails

? ttl?(long, seconds): Time to live in seconds. Values:
    ? 0?or?-1: Not cached or forever cached

    ? > 0: Actual remaining TTL if cached

? stale?(boolean): Whether stale cached data was used (only valid when cached=true). Helps identify semi-error scenarios where DNS errors occur but application continues using stale cached records


Event name:?jdk.DnsCacheStatistics
When:?Periodic event emitted at configurable intervals?(default:?5 seconds in default.jfc,?1 second in profile.jfc).?This is a statistics event similar to?jdk.ExceptionStatistics,?providing aggregate metrics about the DNS cache state.
Key fields (feedback welcome):


? cacheSize?(long): Current number of entries in the DNS cache. Useful for monitoring cache growth and understanding cache utilization patterns.

? staleEntries?(long): Number of stale entries currently in the cache (entries that have expired but are still within the stale period). Helps identify how many entries are using stale data, which is important for understanding cache behavior in scenarios where DNS refresh fails.

? entriesRemoved?(long): Number of entries that have been removed during cache cleanup operations. This metric tracks cache eviction and helps understand cache churn patterns, which is particularly useful in Kubernetes and cloud-native environments where DNS entries may change frequently.


Use cases:


? Monitoring DNS cache size growth over time

? Identifying cache cleanup frequency and patterns

? Understanding stale data usage in production environments

? Troubleshooting DNS-related performance issues in microservices architectures

? Observing cache behavior during DNS server failures or network partitions


Prototype/PR


? A preliminary PR is available for context and discussion:
    ? https://git.openjdk.org/jdk/pull/28110

? I will update the design/implementation per feedback from this thread.


Thanks in advance for your feedback!
Best regards,
NeayGuyCoding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251113/62292a70/attachment-0001.htm>

From dfuchs at openjdk.org  Fri Nov 14 10:10:01 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 10:10:01 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
Message-ID: <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>

On Thu, 13 Nov 2025 14:32:33 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed line wrapping
>
> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:
> 
>> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
>> 103:                 .addBasicConstraintsExt(false, false, -1)
>> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
> 
> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2526848102

From dfuchs at openjdk.org  Fri Nov 14 10:13:07 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 10:13:07 GMT
Subject: Integrated: 8371366:
 java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in
 jtreg timeout
In-Reply-To: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
References: <gHocbZYD7H0kKMO0igrGnX2tQrS-yKTNpj5wwa3vkR4=.cd2ff57d-0434-4fdf-8e98-a45b34e295d0@github.com>
Message-ID: <x1QR-SXPPQ8S_vfCS3wDikUMqn-Ej8oJVOcb5YDoPzI=.8a5bc5fc-4246-4712-8a92-30cc0bd979b6@github.com>

On Thu, 6 Nov 2025 16:22:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Nothing looks wrong with the test or the code. The failure happens rarely - probably when the machine is under load: this test tries to saturate the socket buffers and is resource consuming.
> 
> The proposed fix is just to double the jtreg timeout for this test from 120 to 240.

This pull request has now been integrated.

Changeset: 8a7af77e
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a7af77e991511e144914abc129a9d4d40c0b76b
Stats:     81 lines in 2 files changed: 65 ins; 6 del; 10 mod

8371366: java/net/httpclient/whitebox/RawChannelTestDriver.java fails intermittently in jtreg timeout

Reviewed-by: djelinski, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/28178

From dfuchs at openjdk.org  Fri Nov 14 10:18:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 10:18:15 GMT
Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to
 cover the response body [v15]
In-Reply-To: <TMzPExOcpIHXKkcmQKEWol0z4H7wNhB3KvHjpUdH80w=.e274894f-7e84-4d39-9d66-c28af09eaf40@github.com>
References: <SFmAb-H_ju6V1LUgVA7QYcKPZPE8W8CkhdxCAM6rEBs=.6235a0cd-68d8-4343-81e8-7cc5a6634387@github.com>
 <TMzPExOcpIHXKkcmQKEWol0z4H7wNhB3KvHjpUdH80w=.e274894f-7e84-4d39-9d66-c28af09eaf40@github.com>
Message-ID: <eZvOVyXLa_axVautEBRzLV95D5mpcIn2V7RH5ZvKMWA=.ea159aaf-8192-42a9-9a7f-5bb830fd92cf@github.com>

On Tue, 11 Nov 2025 15:28:29 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body.
>> 
>> ### Review guidelines
>> 
>> 1. Read _"the fix"_ in `MultiExchange`
>> 2. Skim through the test server *handler* in `TimeoutResponseTestSupport`
>> 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!)
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move `cancelTimerOnResponseBodySubscriberTermination` to `ExchangeImpl`

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27469#pullrequestreview-3464166774

From alan.bateman at oracle.com  Fri Nov 14 11:48:43 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Fri, 14 Nov 2025 11:48:43 +0000
Subject: Proposal of introducing new JFR events for DNS lookups
In-Reply-To: <80e7ca0d-640b-48f3-8709-f59b91d4756c@Spark>
References: <80e7ca0d-640b-48f3-8709-f59b91d4756c@Spark>
Message-ID: <9c810286-58a5-4304-b053-fb8dc7ea7762@oracle.com>


It's a good topic to bring up.

Have you tried the JFR support for method timing and tracing events 
that? JEP 520 introduced in JDK 25? I'm wondering if 
-XX:StartFlightRecording:jdk.MethodTrace#filter=java.net.InetAddress::getByName 
records events that could help here.

If new events are introduced then I could image them having 
"NameService" rather than "Dns" in the name as JDK doesn't use DNS 
directly (except the JNDI-DNS provider), it is whatever is configured on 
the system.

-Alan


On 13/11/2025 11:07, hashjangcyber at gmail.com wrote:
> Hello,
> I would like to start a discussion on introducing new JFR events for 
> DNS lookups. While many lookups are DNS in cloud-native environments, 
> the JDK uses the configured name service, so the event naming and 
> semantics should not imply DNS-only behavior. I?m seeking feedback on 
> scope, naming, and payload fields.
> Motivation
>
>   * High-frequency, latency-sensitive lookups are critical for service
>     discovery.
>   * Current gaps:
>       o Cannot distinguish cache hits vs. network lookups
>       o Hard to trace lookup latency and diagnose timeouts/failures
>       o Concurrent libraries may cause redundant lookups
>   * Value:
>       o End-to-end observability: lookup ? socket connect ? data transfer
>       o Troubleshooting: identify timeouts, resolution failures
>       o Performance: evaluate cache policies, detect hotspot names
>       o Security: audit external domains accessed
>
> *Proposed event (initial draft)*
> *Event name:*?jdk.DnsLookup
> *When:*?Emitted around DNS hostname resolution call boundaries,?including:
>
>   * Actual network DNS queries (when cache is disabled or cache miss
>     occurs)
>   * Cache hits (when result is retrieved from DNS cache)
>   * Stale data usage (when expired but still valid cached data is used)
>   * Background DNS cache refresh operations
>
> *Key fields (feedback welcome):*
>
>   * host?(String): The hostname being resolved
>   * result?(String): Comma-separated list of resolved IP addresses, or
>     error message if lookup failed
>   * success?(boolean): Whether the DNS lookup was successful
>   * cached?(boolean): Whether the result was retrieved from cache
>     (true) or from actual DNS network query (false). This helps
>     distinguish between three use cases:
>       o Actual network queries (cached=false) - represents real DNS
>         network traffic
>       o Cache hits (cached=true, stale=false) - repeated lookups using
>         fresh cached data
>       o Stale data usage (cached=true, stale=true) - application
>         continues with expired but still valid cached data when DNS
>         refresh fails
>   * ttl?(long, seconds): Time to live in seconds. Values:
>       o 0?or?-1: Not cached or forever cached
>       o > 0: Actual remaining TTL if cached
>   * stale?(boolean): Whether stale cached data was used (only valid
>     when cached=true). Helps identify semi-error scenarios where DNS
>     errors occur but application continues using stale cached records
>
> *Event name:*?jdk.DnsCacheStatistics
> *When:*?Periodic event emitted at configurable intervals?(default:?5 
> seconds in default.jfc,?1 second in profile.jfc).?This is a statistics 
> event similar to?jdk.ExceptionStatistics,?providing aggregate metrics 
> about the DNS cache state.
> *Key fields (feedback welcome):*
>
>   * cacheSize?(long): Current number of entries in the DNS cache.
>     Useful for monitoring cache growth and understanding cache
>     utilization patterns.
>   * staleEntries?(long): Number of stale entries currently in the
>     cache (entries that have expired but are still within the stale
>     period). Helps identify how many entries are using stale data,
>     which is important for understanding cache behavior in scenarios
>     where DNS refresh fails.
>   * entriesRemoved?(long): Number of entries that have been removed
>     during cache cleanup operations. This metric tracks cache eviction
>     and helps understand cache churn patterns, which is particularly
>     useful in Kubernetes and cloud-native environments where DNS
>     entries may change frequently.
>
> *Use cases:*
>
>   * Monitoring DNS cache size growth over time
>   * Identifying cache cleanup frequency and patterns
>   * Understanding stale data usage in production environments
>   * Troubleshooting DNS-related performance issues in microservices
>     architectures
>   * Observing cache behavior during DNS server failures or network
>     partitions
>
> Prototype/PR
>
>   * A preliminary PR is available for context and discussion:
>       o https://git.openjdk.org/jdk/pull/28110
>         <https://git.openjdk.org/jdk/pull/28110>
>   * I will update the design/implementation per feedback from this thread.
>
> Thanks in advance for your feedback!
> Best regards,
> NeayGuyCoding
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20251114/bc106f14/attachment-0001.htm>

From dfuchs at openjdk.org  Fri Nov 14 13:27:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 13:27:05 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
Message-ID: <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>

On Wed, 12 Nov 2025 15:13:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Update test comments
>  - Convert CubicTest to JUnit
>  - Merge declaration and assignment
>  - More aggressive target growth
>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>  - Make classes final
>  - Rename system property to internal
>  - Add a system property to select congestion controller
>  - Implement fast convergence
>  - Add comments
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicBaseCongestionController.java line 69:

> 67:     protected long maxBytesInFlight;
> 68:     protected Deadline congestionRecoveryStartTime;
> 69:     protected long ssThresh = Long.MAX_VALUE;

Can we remove the `protected` keyword on the mutable fields? All the subclasses are in the same package.

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicBaseCongestionController.java line 84:

> 82:         this.timeSource = source;
> 83:         this.pacer = new QuicPacer(rttEstimator, this);
> 84:     }

Suggestion:

    protected QuicBaseCongestionController(String dbgTag, QuicRttEstimator rttEstimator) {
        this(dbgTag, TimeSource.source(), rttEstimator);
    }

    // Allows to pass a custom TimeLine when testing
    QuicBaseCongestionController(String dbgTag, TimeLine source, QuicRttEstimator rttEstimator) {
        this.dbgTag = dbgTag;
        this.timeSource = source;
        this.pacer = new QuicPacer(rttEstimator, this);
    }

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 67:

> 65:     // for testing
> 66:     public QuicCubicCongestionController(TimeLine source, QuicRttEstimator rttEstimator) {
> 67:         super(source, rttEstimator);

Suggestion:

        super("TEST", source, rttEstimator);

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 114:

> 112:         if (!isAppLimited) {
> 113:             if (wEstBytes < cwndPriorBytes) {
> 114:                 wEstBytes += Math.max((long) (ALPHA * maxDatagramSize * packetBytes / congestionWindow), 1);

should we assert that congestionWindow is > 2 ?

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 124:

> 122:             // not sure if dblTarget can overflow a long, but 1.5 congestionWindow can not.
> 123:             if (dblTargetBytes > 1.5 * congestionWindow) {
> 124:                 targetBytes = (long) (1.5 * congestionWindow);

Suggestion:

            // targetLimit is 1.5 * congestionWindow
            long targetLimit = congestionWindow + (congestionWindow >> 1)
            if (dblTargetBytes > targetLimit) {
                targetBytes = targetLimit;

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 129:

> 127:             }
> 128:             if (targetBytes > congestionWindow) {
> 129:                 congestionWindow += Math.max((targetBytes - congestionWindow) * packetBytes / congestionWindow, 1L);

Can `(targetBytes - congestionWindow) * packetBytes / congestionWindow` overflow?

src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 162:

> 160:         lastFullWindow = congestionRecoveryStartTime;
> 161:         // ((wmax_segments - cwnd_segments) / C) ^ (1/3) seconds
> 162:         kNanos = (long)(Math.cbrt((wMaxBytes - congestionWindow) / C / maxDatagramSize) * 1_000_000_000);

should we assert that wMaxBytes >=  congestionWindow ? It is not immediately obvious to me that this is guaranteed.

In particular:


        if (congestionWindow < wMaxBytes) {
            // fast convergence
            wMaxBytes = (long) ((1 + BETA) * congestionWindow / 2);


seems to imply that `wMaxBytes` will be less than congestion window since 1.7 < 2

So we would end up with a negative value for kNanos, which is defined as:

> The time period in seconds it takes to increase the congestion window size at the beginning of the current congestion avoidance stage to Wmax.

so presumably negative values for kNanos are not expected?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527297674
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527332413
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527340117
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527400131
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527418638
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527429228
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527493627

From dfuchs at openjdk.org  Fri Nov 14 13:27:06 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 13:27:06 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
Message-ID: <r3ieSzkVzYHU5LXdUlIX0pdkhBPVnK-PZxKN64esdWk=.bc266a4c-2aa0-44fb-8fa1-c1bae284c700@github.com>

On Fri, 14 Nov 2025 13:03:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Update test comments
>>  - Convert CubicTest to JUnit
>>  - Merge declaration and assignment
>>  - More aggressive target growth
>>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>>  - Make classes final
>>  - Rename system property to internal
>>  - Add a system property to select congestion controller
>>  - Implement fast convergence
>>  - Add comments
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 129:
> 
>> 127:             }
>> 128:             if (targetBytes > congestionWindow) {
>> 129:                 congestionWindow += Math.max((targetBytes - congestionWindow) * packetBytes / congestionWindow, 1L);
> 
> Can `(targetBytes - congestionWindow) * packetBytes / congestionWindow` overflow?

Should we assert that congestionWindow is >= minimumWindow after this operation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2527438742

From mail at laeubi-soft.de  Fri Nov 14 14:43:17 2025
From: mail at laeubi-soft.de (=?UTF-8?Q?Christoph_L=C3=A4ubrich?=)
Date: Fri, 14 Nov 2025 15:43:17 +0100
Subject: [request-for-comments] on making GOAWAY handling more explicit
Message-ID: <05ffd008-326c-4e23-a4f9-bb18caeb98b5@laeubi-soft.de>

Hello everyone,

I have created a small overview here about a topic currently hard to 
tackle when servers send GOAWAY the current generic IOException leaves 
the client quite "blind" what has happened, details are described here:

https://github.com/laeubi/java-http-client/issues/8

I would appreciate feedback/thoughts from other about the topic either 
here or at the issue itself!

From dfuchs at openjdk.org  Fri Nov 14 15:00:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 15:00:23 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v12]
In-Reply-To: <BkKKQhFzjR0ezI-X5a-Mq5EjO0Hw2J2_qbXFY0QfUoU=.1b2ba3c3-0bc7-4b75-8232-b464781347db@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <BkKKQhFzjR0ezI-X5a-Mq5EjO0Hw2J2_qbXFY0QfUoU=.1b2ba3c3-0bc7-4b75-8232-b464781347db@github.com>
Message-ID: <hCIXQ-ro8VKN0iJurKHZveAFDZ528hf27x-LrTkSYZA=.800135cf-c735-4904-ace3-3879f69e8bdf@github.com>

On Thu, 6 Nov 2025 10:34:45 GMT, Peyang <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
>> 
>> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
>> 
>> This change contains:
>> 
>> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
>> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
>> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
>> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
>> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
>> 6. Includes corresponding tests to verify correct behavior.
>> 
>> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
>> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html
>
> Peyang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace IOException with EOFException for unexpected EOF in FileServerHandler

test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java line 146:

> 144:                         1000L, "bytes=100-199,300-399,150-350",
> 145:                         new FileServerHandler.RangeEntry(100,399)
> 146:                 },

Can we add a test with duplicated ranges too? e.g.

`0-99,200-399,0-99,400-499,200-499`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2527806888

From dfuchs at openjdk.org  Fri Nov 14 15:32:50 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 15:32:50 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
Message-ID: <srFbufK50Z4o3m9ynlel79xDBINY2lj5Hu4xzdhWMsA=.ed8e440e-6610-423b-b1fc-28d8a22e86a8@github.com>

On Wed, 12 Nov 2025 15:13:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Update test comments
>  - Convert CubicTest to JUnit
>  - Merge declaration and assignment
>  - More aggressive target growth
>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>  - Make classes final
>  - Rename system property to internal
>  - Add a system property to select congestion controller
>  - Implement fast convergence
>  - Add comments
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89

And another question: after this change - do we still have tests for the Reno congestion controller? Or is everthing using Cubic?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28195#issuecomment-3533300315

From dfuchs at openjdk.org  Fri Nov 14 16:35:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 16:35:57 GMT
Subject: RFR: 8371916: Questionable volatile decrement in AckFrameSpliterator
Message-ID: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>

AckFrameSpliterator defines volatile fields. Since Spliterator is not supposed to be MT-safe volatile are not needed there. This change also include some other minor cleanup.

-------------

Commit messages:
 - 8371916: Questionable volatile decrement in AckFrameSpliterator

Changes: https://git.openjdk.org/jdk/pull/28325/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28325&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371916
  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28325.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28325/head:pull/28325

PR: https://git.openjdk.org/jdk/pull/28325

From dfuchs at openjdk.org  Fri Nov 14 17:11:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 14 Nov 2025 17:11:31 GMT
Subject: RFR: 8371557: java/net/httpclient/http3/H3RequestRejectedTest.java:
 javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote
 endpoint (loopback) ports conflict
Message-ID: <bOyTNOjcEMePV95K5pS9VCEMrsUk7kGVAQZYMYAbp38=.7ac0671f-aa56-4828-8d00-446d0bf1f9c5@github.com>

java/net/httpclient/http3/H3RequestRejectedTest.java fails intermittently (rarely) on macOS with javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote endpoint (loopback) ports conflict.

This is a well known issue on macOS, which can be avoided by having the client bind specifically to the loopback instead of the wildcard.

A couple of methods have been added to HttpServerAdapters (newClientBuilderForH3() / createClientBuilderForH3()) to obtain a client builder pre-configured to bind to the loopback.

Most HTTP/3 test call those methods, but java/net/httpclient/http3/H3RequestRejectedTest.java doesn't, hence the intermittent failure.

-------------

Commit messages:
 - 8371557: java/net/httpclient/http3/H3RequestRejectedTest.java: javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote endpoint (loopback) ports conflict

Changes: https://git.openjdk.org/jdk/pull/28326/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28326&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371557
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28326.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28326/head:pull/28326

PR: https://git.openjdk.org/jdk/pull/28326

From duke at openjdk.org  Sat Nov 15 16:55:03 2025
From: duke at openjdk.org (EunHyunsu)
Date: Sat, 15 Nov 2025 16:55:03 GMT
Subject: RFR: 8328894: HttpResponse.body() returns null with https target
 and failed proxy authentication
In-Reply-To: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>
References: <rZWs6dfytoglAKMHnuxy8KyV4MzsM67funSgAwQbDI8=.37a02dab-8f12-4cb2-89b5-c26bf81908a4@github.com>
Message-ID: <1BVAdmuUQ4WobDrgy2K1AxDs4wKL8uXhqJ2ZZdNWDUQ=.496d0b9a-c323-4b56-8f3a-c03aeca0a423@github.com>

On Tue, 11 Nov 2025 11:31:22 GMT, EunHyunsu <duke at openjdk.org> wrote:

> ### Summary
>   This patch addresses the issue where `HttpResponse.body()` returns `null` for 407 responses when using HTTPS through a proxy, while HTTP requests correctly return the response body.
> 
>   ### Problem
>   When an HTTPS request receives a 407 Proxy Authentication Required response, the response body is discarded during CONNECT tunnel establishment. This is inconsistent with HTTP behavior where the body is properly returned.
> 
>   **Root cause:**
>   - HTTPS uses `MultiExchange<Void>` for CONNECT requests
>   - The body is explicitly ignored via `ignoreBody()` on 407 responses
>   - No mechanism exists to preserve the body for later retrieval
> 
>   ### Proposed Solution
>   I propose the following changes to preserve and return the 407 response body:
> 
>   1. **PlainTunnelingConnection.java**: Change `MultiExchange<Void>` to `MultiExchange<byte[]>` and read the body on 407 responses instead of ignoring it
> 
>   2. **ProxyAuthenticationRequired.java**: Add `proxyResponseBody` field to carry the body bytes through the exception
> 
>   3. **Exchange.java**: Cache both the proxy response and body, then return them when the application calls `body()`
> 
>   ### Testing
>   Added comprehensive test (`ProxyAuthHttpTest.java`) covering:
>   - Basic HTTP and HTTPS 407 responses
>   - Multiple `BodyHandler` types: `ofString()`, `ofByteArray()`, `ofInputStream()`, `ofLines()`
>   - Response headers validation
> 
>   **Test results**: 38/38 passed
> 
>   ### Notes
>   - This change only affects 407 responses; all other flows remain unchanged
>   - The cached body is cleared after first use to prevent reuse
>   - No changes to public APIs; internal implementation only
> 
>   I'd appreciate any feedback on this approach. If there's a better way to handle this, I'm happy to revise.

@dfuchs Thank you for the detailed feedback!

You're absolutely right about the memory concerns with forced byte[] conversion. 
I noticed that `Http1Response.ignoreBody()` uses a similar pattern with `MAX_IGNORE = 1024` for handling redirect response bodies. We could apply a comparable approach here:


private static final int MAX_PROXY_ERROR_BODY = 8192; // or 16384

if (resp.statusCode() == 407) {
    long contentLength = resp.headers()
        .firstValueAsLong("Content-Length").orElse(-1);

    if (contentLength >= 0 && contentLength <= MAX_PROXY_ERROR_BODY) {
        // Read and cache body
        return connectExchange.readBodyAsync(ofByteArray())...
    } else {
        // Close connection without reading body
        delegate.close();
        return MinimalFuture.failedFuture(
            new ProxyAuthenticationRequired(resp, null));
    }
}

This would limit memory usage while still fixing the issue for most real-world 407 responses (which are typically small HTML error pages).

Alternatively, if there's a way to preserve the MultiExchange<Void> approach while still making the body available to the application layer, I'd be happy to explore that direction. Please let me know if you have suggestions.

I completely understand the timing concern regarding RDP 1. I'm happy to wait until after the fork to continue this discussion. Thank you for considering this contribution!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28232#issuecomment-3536668851

From duke at openjdk.org  Sun Nov 16 06:18:06 2025
From: duke at openjdk.org (Peyang)
Date: Sun, 16 Nov 2025 06:18:06 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v13]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <fPnjvCEjoCd8eBIDd8uCCR-AQ-Ot0r2EGHqfX1yt5pE=.708c6d52-fee6-418d-9138-5d42df15a8ba@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request incrementally with two additional commits since the last revision:

 - Fix HTTP Range header test case for invalid range format
 - Add test case for duplicate and overlapping HTTP Range headers
   
   Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28021/files
  - new: https://git.openjdk.org/jdk/pull/28021/files/060ebc00..53004b61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=11-12

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From duke at openjdk.org  Sun Nov 16 09:52:01 2025
From: duke at openjdk.org (Peyang)
Date: Sun, 16 Nov 2025 09:52:01 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v14]
In-Reply-To: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
Message-ID: <T-CIixy1Z1cZiulON4bYYUXBtnnrz62mljQI0eaYDBY=.90e6d066-43bb-49ec-9f10-0776ec463ef3@github.com>

> Hi all,
> 
> [JEP 408](https://openjdk.org/jeps/408) introduced the Simple Web Server in Java 18, providing a minimal webserver for serving static files over HTTP.
> 
> [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-range-requests) defines "Range Requests" as an optional feature that allows clients to request a subset of a resource's content. Supporting Range requests in the context of JDK's Simple Web Server means enabling the server to serve only the requested portion of a static file.
> 
> This change contains:
> 
> 1. Enhances `sun.net.httpserver.simpleserver.FileServerHandler` in the `jdk.httpserver` module to support `Range` and `If-Range` headers.
> 2. Calculates an `ETag` for each resource based on its last-modified date and file size and sends it to the client on demand for use with the `If-Range` header.
> 3. Returns the `Accept-Ranges` header for all file retrievals, and `Content-Range` when a client requests a specific range.
> 4. Adds a new constant `HTTP_RANGE_NOT_SATISFIABLE` to the `Codes` class to indicate invalid ranges.
> 5. Returns `206 Partial Content` for valid ranges and `416 Range Not Satisfiable` for invalid ranges.
> 6. Includes corresponding tests to verify correct behavior.
> 
> This enhancement was motivated by recent discussions on the net-dev mailing list, which requested support for Range requests along with example use cases: https://mail.openjdk.org/pipermail/net-dev/2025-April/026364.html
> It was also discussed briefly on the net-dev mailing list: https://mail.openjdk.org/pipermail/net-dev/2025-October/028586.html

Peyang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'master' into 8355572-support-http-range-header
 - Fix HTTP Range header test case for invalid range format
 - Add test case for duplicate and overlapping HTTP Range headers
   
   Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
 - Replace IOException with EOFException for unexpected EOF in FileServerHandler
 - Throw IOException on unexpected EOF while reading file in FileServerHandler
 - Implement range normalization for overlapping and contiguous HTTP Range headers
 - Add additional test cases for invalid HTTP Range header formats
 - Refactor parsing of HTTP Range header to remove radix specification in Long.parseLong calls
 - Add assertion to ensure end range value valid in HTTP Range header processing
 - Allow unlimited splits when parsing HTTP Range header to detect trailing commas
 - ... and 20 more: https://git.openjdk.org/jdk/compare/f510b4a3...082a76dc

-------------

Changes: https://git.openjdk.org/jdk/pull/28021/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=13
  Stats: 435 lines in 6 files changed: 423 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021

PR: https://git.openjdk.org/jdk/pull/28021

From vyazici at openjdk.org  Mon Nov 17 08:32:01 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 17 Nov 2025 08:32:01 GMT
Subject: RFR: 8371916: Questionable volatile decrement in
 AckFrameSpliterator
In-Reply-To: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
References: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
Message-ID: <hPKBCzQgZUUsOlfEb-2QndQBu2Cuy-3wRZVDDXGZ8tU=.d582f871-d16a-4786-8f10-2c571f9f6d69@github.com>

On Fri, 14 Nov 2025 16:27:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> AckFrameSpliterator defines volatile fields. Since Spliterator is not supposed to be MT-safe volatile are not needed there. This change also include some other minor cleanup.

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28325#pullrequestreview-3471530382

From jpai at openjdk.org  Mon Nov 17 09:35:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 09:35:10 GMT
Subject: RFR: 8371916: Questionable volatile decrement in
 AckFrameSpliterator
In-Reply-To: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
References: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
Message-ID: <kGbD5RGs84gOkXts-K1Z5LCio5KlEV6E77_AYSpEa9c=.4776ab20-96da-42f9-941b-26be037e3e9b@github.com>

On Fri, 14 Nov 2025 16:27:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> AckFrameSpliterator defines volatile fields. Since Spliterator is not supposed to be MT-safe volatile are not needed there. This change also include some other minor cleanup.

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28325#pullrequestreview-3471828516

From djelinski at openjdk.org  Mon Nov 17 10:43:05 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Nov 2025 10:43:05 GMT
Subject: RFR: 8371916: Questionable volatile decrement in
 AckFrameSpliterator
In-Reply-To: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
References: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
Message-ID: <uz3l1Gfab-8DCFTNujEATs859CbJsBP6taz_sDuD2RI=.2860beb3-ea9c-4298-babf-0579c2338442@github.com>

On Fri, 14 Nov 2025 16:27:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> AckFrameSpliterator defines volatile fields. Since Spliterator is not supposed to be MT-safe volatile are not needed there. This change also include some other minor cleanup.

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28325#pullrequestreview-3472084862

From alan.bateman at oracle.com  Mon Nov 17 10:47:23 2025
From: alan.bateman at oracle.com (Alan Bateman)
Date: Mon, 17 Nov 2025 10:47:23 +0000
Subject: Proposal of introducing new JFR events for DNS lookups
In-Reply-To: <4101d5dc-b28d-4f51-b94e-8e5479790e7c@Spark>
References: <80e7ca0d-640b-48f3-8709-f59b91d4756c@Spark>
 <9c810286-58a5-4304-b053-fb8dc7ea7762@oracle.com>
 <4101d5dc-b28d-4f51-b94e-8e5479790e7c@Spark>
Message-ID: <bd85902e-2f92-44c8-ba2b-cba0e2bf3aeb@oracle.com>



On 15/11/2025 00:53, hashjangcyber at gmail.com wrote:
> Yeah, I agree:
> 1. The latest method profiling can identify the problem. But it can be 
> identified only if user know or suspect that there maybe some blocking 
> in InetAddress::getByName
> 2. The event is introduced and can be enabled by default to help 
> identify the problem when problem emerges.
> 3. Yeah, it is more reasonable for having "NameService" rather than "Dns"
>
My guess is that you aren't subscribed to net-dev with this mail 
address, this is why your messages aren't getting to the list.

-Alan



From jpai at openjdk.org  Mon Nov 17 10:59:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 10:59:18 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Mb_KZKkQ52_a4XunDYYH7YTsoN14KuNjHIAX5hF3tGo=.cfca3715-eafa-466e-82e2-fbf195393054@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>
 <Mb_KZKkQ52_a4XunDYYH7YTsoN14KuNjHIAX5hF3tGo=.cfca3715-eafa-466e-82e2-fbf195393054@github.com>
Message-ID: <vdKiffb83jtH8B76QR-G3dlyZkhOV09Up2pj4YjvGtw=.2f3ce89a-25ee-41e9-b6fb-440360523256@github.com>

On Wed, 12 Nov 2025 10:11:22 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 84:
>> 
>>> 82:      * such cases.
>>> 83:      */
>>> 84:     public abstract boolean isErroneousClose();
>> 
>> nit: can we use a different word here? "Erroneous close" feels vague here; would "is(Non)Graceful", "isAbrupt" or "hasErrorCode" capture the intent?
>
> That that `erroneous close` has been used in several other contexts; in code, in comments, etc. If this gets updated, I'd appreciate other relevant occurrences get updated too.

Would `isAbnormalClose()` be better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533617843

From dfuchs at openjdk.org  Mon Nov 17 11:04:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Nov 2025 11:04:16 GMT
Subject: RFR: 8371916: Questionable volatile decrement in
 AckFrameSpliterator
In-Reply-To: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
References: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
Message-ID: <8fQqryO1mRgoRzglZlsCgh3_JHFdsU3vMOg46Grn7YQ=.2a2842ef-4388-4203-9a0d-3a38becc9514@github.com>

On Fri, 14 Nov 2025 16:27:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> AckFrameSpliterator defines volatile fields. Since Spliterator is not supposed to be MT-safe volatile are not needed there. This change also include some other minor cleanup.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28325#issuecomment-3541182575

From dfuchs at openjdk.org  Mon Nov 17 11:04:17 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Nov 2025 11:04:17 GMT
Subject: Integrated: 8371916: Questionable volatile decrement in
 AckFrameSpliterator
In-Reply-To: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
References: <5w8T8buNY1bhbSM7x3lKyzHDeO-WXYk1-BXSVCxEA38=.beb89da6-5cf4-4c37-99c7-44e54256e885@github.com>
Message-ID: <irs0n5EbMt9cvPAcCsY64z9O7-E7_0DEa4KQPx-FRG0=.d3ba1f83-9b55-4002-b832-c77fd8e12de2@github.com>

On Fri, 14 Nov 2025 16:27:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> AckFrameSpliterator defines volatile fields. Since Spliterator is not supposed to be MT-safe volatile are not needed there. This change also include some other minor cleanup.

This pull request has now been integrated.

Changeset: d19e072f
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d19e072f97681cfc50a8c7b96a25589070436a10
Stats:     13 lines in 1 file changed: 0 ins; 0 del; 13 mod

8371916: Questionable volatile decrement in AckFrameSpliterator

Reviewed-by: vyazici, jpai, djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/28325

From jpai at openjdk.org  Mon Nov 17 12:06:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:06:41 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v3]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <w8roFJcCBxk-mINlhbDeFn-fJbe1nSpqkP548d88tnM=.22369ea6-b4f8-4ee8-8070-9f894afbba5f@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - rename isErroneousClose() to isAbnormalClose()
 - stackless instance for idle timed out NoError
 - Volkan's suggestion - log message improvement
 - merge latest from master branch
 - mark jdk.internal.net.http.Http2Connection as Closable
 - reduce number of concurrent requests
 - cleanup
 - update test
 - Return false from isOpen() if underlying channel is not open
 - Daniel's review suggestion - stop the scheduler when TubeSubscriber errored or completed
 - ... and 2 more: https://git.openjdk.org/jdk/compare/3b9f58c2...1c3f73ba

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/3e4574b4..1c3f73ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=01-02

  Stats: 14028 lines in 236 files changed: 7709 ins; 4841 del; 1478 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Mon Nov 17 12:06:43 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:06:43 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v3]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <bE5NkfS01t5FTXVEcUunIkkh4VMjCydRZ-QOPhPUSF0=.49363ebc-378a-4d9b-9b7d-eacd57d48def@github.com>

On Wed, 12 Nov 2025 09:08:43 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - rename isErroneousClose() to isAbnormalClose()
>>  - stackless instance for idle timed out NoError
>>  - Volkan's suggestion - log message improvement
>>  - merge latest from master branch
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>>  - cleanup
>>  - update test
>>  - Return false from isOpen() if underlying channel is not open
>>  - Daniel's review suggestion - stop the scheduler when TubeSubscriber errored or completed
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/3b9f58c2...1c3f73ba
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 234:
> 
>> 232:                 if (cancelled) {
>> 233:                     if (debug.on()) {
>> 234:                         debug.log("Not initiating idle connection close");
> 
> Suggestion:
> 
>                         debug.log("Connection is already cancelled, skipping idle connection close");

I updated the PR with a slightly different message - it's not the connection which is cancelled but it is the idle timeout event which is cancelled.

> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 144:
> 
>> 142:      */
>> 143:     public static Http2TerminationCause idleTimedOut() {
>> 144:         return new NoError("HTTP/2 connection idle timed out", "idle timed out");
> 
> Any particular reason this is not cached in `NoError.IDLE_TIMED_OUT` in a similar manner to `NoError.INSTANCE`? I could not see a place where its stack trace would be of value.

You are right, the idle timed out instance could also do away with the stacktrace. I have updated the PR with this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533799723
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533797755

From jpai at openjdk.org  Mon Nov 17 12:06:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:06:44 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <vdKiffb83jtH8B76QR-G3dlyZkhOV09Up2pj4YjvGtw=.2f3ce89a-25ee-41e9-b6fb-440360523256@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <exnin3L_Hjwy4Y5_3UZ4Yzlq-vBx-8nu3jahYiNmwSc=.2daf0256-998c-482f-a025-e44cd4469f61@github.com>
 <Mb_KZKkQ52_a4XunDYYH7YTsoN14KuNjHIAX5hF3tGo=.cfca3715-eafa-466e-82e2-fbf195393054@github.com>
 <vdKiffb83jtH8B76QR-G3dlyZkhOV09Up2pj4YjvGtw=.2f3ce89a-25ee-41e9-b6fb-440360523256@github.com>
Message-ID: <8gY624zusVZfLEfo2J8LxuFehSrSdFcz3m_wk4KJFos=.74da5a79-d503-46bd-8db4-a2316444ffbf@github.com>

On Mon, 17 Nov 2025 10:56:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> That that `erroneous close` has been used in several other contexts; in code, in comments, etc. If this gets updated, I'd appreciate other relevant occurrences get updated too.
>
> Would `isAbnormalClose()` be better?

I updated the PR to use `isAbnormalClose()`. I can rename it further if necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533801903

From jpai at openjdk.org  Mon Nov 17 12:16:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:16:35 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v4]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <TOKIFONwMvwOn0GtoYkfCY1z7pk_2zM4SIV-OGuuhq0=.b8f57e22-15bc-4c73-a224-2a0157eab0cb@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  trivial debug log check change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/1c3f73ba..c9d89cc9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=02-03

  Stats: 8 lines in 1 file changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Mon Nov 17 12:16:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:16:35 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v4]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <fOST3V9olRdsi_ncMKjTrlHc10ShoXASfTzgI-ICDzU=.85cb7517-5c7b-4497-853a-95565c7cf392@github.com>

On Wed, 12 Nov 2025 09:30:09 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trivial debug log check change
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2056:
> 
>> 2054:         private void doTerminate() {
>> 2055:             final Http2TerminationCause tc = terminationCause.get();
>> 2056:             assert tc != null : "missing termination cause";
> 
> `doTerminate()` can receive the termination cause from `terminate()`, which would render these two lines redundant.

Actually, this one was intentional. I wanted to avoid introducing a `doTerminate(cause)` (even if `private`) which could then be invoked from arbitrary places with different causes.

In doTerminate() I always want it to use the cause that's already set and setting of that cause must always happen in `terminate(cause)`. terminate(cause) itself is allowed to be called from numerous places and it has the necessary code to synchronize in a way that allows setting the cause just once and then calling doTerminate() just once.

> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2076:
> 
>> 2074:                 Log.logError("Closing connection due to: {0}", tc);
>> 2075:             } else {
>> 2076:                 if (debug.on()) {
> 
> You can consider simplifying this as `else if (debug.on())`.

Good catch. Fixed in the updated PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533823365
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533830866

From jpai at openjdk.org  Mon Nov 17 12:20:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:20:13 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <arM4A-J4kkUzM-9DLHEdrog_5JvZAt-v7uXfxFb0xwo=.4d2c1501-cee2-41f5-af6b-ea54573ed7c7@github.com>

On Wed, 12 Nov 2025 10:16:47 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2071:
> 
>> 2069:                             peerVisibleReason.getBytes(UTF_8));
>> 2070:                 }
>> 2071:                 sendGoAway(goAway);
> 
> Do we need to take `sendGoAway()` failures into account?

In its current form sendGoAway() does not throw any checked exceptions. Our general coding practice has been to not introduce try/catch block for such calls and if such methods do end up throwing some (Runtime)Exception, we fix the issue at the place where that unexpected (Runtime)Exception gets thrown or introduce a throws clause on such methods.

Having said that, if desired, I'm open to updating this line to have a try/catch for the generic `Exception` which then merely logs that the GOAWAY frame could not be enqueued.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533844455

From jpai at openjdk.org  Mon Nov 17 12:28:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:28:35 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v5]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <9UZT300xVhV88-9qnfOUiw5j3HCfqe5c3HJgz-j4p8c=.96562cab-0b1d-4581-80c5-ad215a7e104b@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  fix typo in test code comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/c9d89cc9..f4ed10d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Mon Nov 17 12:28:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 17 Nov 2025 12:28:37 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <dbiTe4ooajXLJ1B_9V0h5l8yjHngaY6kWl5rtzgZ-KA=.36fa3084-215f-47e8-a946-c11730a8486f@github.com>

On Wed, 12 Nov 2025 10:50:01 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 128:
> 
>> 126: 
>> 127:     /*
>> 128:      * Issues a burst of 100 HTTP/2 requests to the same server (host/port) and expects all of
> 
> `numRequests` is actually 20, not 100:
> 
> Suggestion:
> 
>      * Issues a burst of HTTP/2 requests to the same server (host/port) and expects all of

Good catch. This was a left over from a change where I reduced the count to 20. I have fixed this comment now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2533866188

From djelinski at openjdk.org  Mon Nov 17 12:41:11 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Nov 2025 12:41:11 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
Message-ID: <0vLD4TJVLBgs0Kq66JBsL1YO5dg2QeKTOWDtA1yYE-c=.1c7036f3-d37a-44c7-8201-b1cdab1abc12@github.com>

On Fri, 14 Nov 2025 12:53:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Update test comments
>>  - Convert CubicTest to JUnit
>>  - Merge declaration and assignment
>>  - More aggressive target growth
>>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>>  - Make classes final
>>  - Rename system property to internal
>>  - Add a system property to select congestion controller
>>  - Implement fast convergence
>>  - Add comments
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 114:
> 
>> 112:         if (!isAppLimited) {
>> 113:             if (wEstBytes < cwndPriorBytes) {
>> 114:                 wEstBytes += Math.max((long) (ALPHA * maxDatagramSize * packetBytes / congestionWindow), 1);
> 
> should we assert that congestionWindow is > 2 ?

The congestion window is in bytes, and it's never reduced below 2*maxDatagramSize, which is never less than 2400. Not sure if we should add that particular assertion, but it would probably make sense to assert that packetAcked does not decrease the congestion window. I'll see what I can do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2533913741

From djelinski at openjdk.org  Mon Nov 17 12:44:14 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Nov 2025 12:44:14 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <r3ieSzkVzYHU5LXdUlIX0pdkhBPVnK-PZxKN64esdWk=.bc266a4c-2aa0-44fb-8fa1-c1bae284c700@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <r3ieSzkVzYHU5LXdUlIX0pdkhBPVnK-PZxKN64esdWk=.bc266a4c-2aa0-44fb-8fa1-c1bae284c700@github.com>
Message-ID: <HokEl9CQdNIi_dteVhqCairjr_MbN5GjOagQ9GFVcu8=.59858dd9-4c59-4d6a-bec1-9e45101beba2@github.com>

On Fri, 14 Nov 2025 13:06:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 129:
>> 
>>> 127:             }
>>> 128:             if (targetBytes > congestionWindow) {
>>> 129:                 congestionWindow += Math.max((targetBytes - congestionWindow) * packetBytes / congestionWindow, 1L);
>> 
>> Can `(targetBytes - congestionWindow) * packetBytes / congestionWindow` overflow?
>
> Should we assert that congestionWindow is >= minimumWindow after this operation?

It cannot overflow when used correctly (i.e. when packetBytes < congestionWindow, and congestionWindow < 2 * MAX_BYTES_IN_FLIGHT).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2533924596

From djelinski at openjdk.org  Mon Nov 17 12:51:08 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 17 Nov 2025 12:51:08 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
Message-ID: <sXuj3QyJBLMQvck8ixdsJypetftId5jQC4YEXckTBqM=.871b7a6c-55a9-497a-b15f-4feff91f366e@github.com>

On Fri, 14 Nov 2025 13:22:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Update test comments
>>  - Convert CubicTest to JUnit
>>  - Merge declaration and assignment
>>  - More aggressive target growth
>>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>>  - Make classes final
>>  - Rename system property to internal
>>  - Add a system property to select congestion controller
>>  - Implement fast convergence
>>  - Add comments
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 162:
> 
>> 160:         lastFullWindow = congestionRecoveryStartTime;
>> 161:         // ((wmax_segments - cwnd_segments) / C) ^ (1/3) seconds
>> 162:         kNanos = (long)(Math.cbrt((wMaxBytes - congestionWindow) / C / maxDatagramSize) * 1_000_000_000);
> 
> should we assert that wMaxBytes >=  congestionWindow ? It is not immediately obvious to me that this is guaranteed.
> 
> In particular:
> 
> 
>         if (congestionWindow < wMaxBytes) {
>             // fast convergence
>             wMaxBytes = (long) ((1 + BETA) * congestionWindow / 2);
> 
> 
> seems to imply that `wMaxBytes` will be less than congestion window since 1.7 < 2
> 
> So we would end up with a negative value for kNanos, which is defined as:
> 
>> The time period in seconds it takes to increase the congestion window size at the beginning of the current congestion avoidance stage to Wmax.
> 
> so presumably negative values for kNanos are not expected?

Well that's an interesting question. The RFC does not suggest clamping wMaxBytes in any way, so we sometimes do end up with wMaxBytes < congestionWindow, and kNanos < 0, even in the `testReduction` test. That seems to be in line with the RFC.

A negative `k` value is pretty well tolerated by the algorithm. It just means that we will start increasing the window slightly faster than we would otherwise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2533944799

From dfuchs at openjdk.org  Mon Nov 17 15:20:29 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Nov 2025 15:20:29 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <sXuj3QyJBLMQvck8ixdsJypetftId5jQC4YEXckTBqM=.871b7a6c-55a9-497a-b15f-4feff91f366e@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <sXuj3QyJBLMQvck8ixdsJypetftId5jQC4YEXckTBqM=.871b7a6c-55a9-497a-b15f-4feff91f366e@github.com>
Message-ID: <mM6bzC4BPBu-sNNCpVAt-QqdrgzYTCIv0lE4o25J_dE=.ca6959dc-e072-4f0e-a4de-584c469cbc65@github.com>

On Mon, 17 Nov 2025 12:48:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 162:
>> 
>>> 160:         lastFullWindow = congestionRecoveryStartTime;
>>> 161:         // ((wmax_segments - cwnd_segments) / C) ^ (1/3) seconds
>>> 162:         kNanos = (long)(Math.cbrt((wMaxBytes - congestionWindow) / C / maxDatagramSize) * 1_000_000_000);
>> 
>> should we assert that wMaxBytes >=  congestionWindow ? It is not immediately obvious to me that this is guaranteed.
>> 
>> In particular:
>> 
>> 
>>         if (congestionWindow < wMaxBytes) {
>>             // fast convergence
>>             wMaxBytes = (long) ((1 + BETA) * congestionWindow / 2);
>> 
>> 
>> seems to imply that `wMaxBytes` will be less than congestion window since 1.7 < 2
>> 
>> So we would end up with a negative value for kNanos, which is defined as:
>> 
>>> The time period in seconds it takes to increase the congestion window size at the beginning of the current congestion avoidance stage to Wmax.
>> 
>> so presumably negative values for kNanos are not expected?
>
> Well that's an interesting question. The RFC does not suggest clamping wMaxBytes in any way, so we sometimes do end up with wMaxBytes < congestionWindow, and kNanos < 0, even in the `testReduction` test. That seems to be in line with the RFC.
> 
> A negative `k` value is pretty well tolerated by the algorithm. It just means that we will start increasing the window slightly faster than we would otherwise.

OK then. Could be worth adding a comment that kNanos can be negative and that is OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2534491636

From dfuchs at openjdk.org  Mon Nov 17 15:28:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Nov 2025 15:28:05 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <HokEl9CQdNIi_dteVhqCairjr_MbN5GjOagQ9GFVcu8=.59858dd9-4c59-4d6a-bec1-9e45101beba2@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <r3ieSzkVzYHU5LXdUlIX0pdkhBPVnK-PZxKN64esdWk=.bc266a4c-2aa0-44fb-8fa1-c1bae284c700@github.com>
 <HokEl9CQdNIi_dteVhqCairjr_MbN5GjOagQ9GFVcu8=.59858dd9-4c59-4d6a-bec1-9e45101beba2@github.com>
Message-ID: <3yNjwr_b3mSZbMjeZ96UPD5uljqf0ovW97qgpCRiokI=.3f5958d1-0d09-489c-86a5-11196f81498d@github.com>

On Mon, 17 Nov 2025 12:41:39 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Should we assert that congestionWindow is >= minimumWindow after this operation?
>
> It cannot overflow when used correctly (i.e. when packetBytes < congestionWindow, and congestionWindow < 2 * MAX_BYTES_IN_FLIGHT).

if congestionWindow >= minimumWindow is an invariant, maybe we should assert it whenever we change congestionWindow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2534518143

From dfuchs at openjdk.org  Mon Nov 17 15:48:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 17 Nov 2025 15:48:11 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v5]
In-Reply-To: <9UZT300xVhV88-9qnfOUiw5j3HCfqe5c3HJgz-j4p8c=.96562cab-0b1d-4581-80c5-ad215a7e104b@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9UZT300xVhV88-9qnfOUiw5j3HCfqe5c3HJgz-j4p8c=.96562cab-0b1d-4581-80c5-ad215a7e104b@github.com>
Message-ID: <EuGb3Tx482T5M9VxTq2-TFu2B1lJtnriN9CHDMU7SSk=.ca24f010-b4a5-4821-9060-01dce2165202@github.com>

On Mon, 17 Nov 2025 12:28:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo in test code comment

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2022:

> 2020:         if (debug.on()) {
> 2021:             debug.log("sending GOAWAY " + goAway);
> 2022:         }

Suggestion:

        if (Log.trace()) {
            Log.logTrace("{0} sending GOAWAY {1}", connection, goAway);
        } else if (debug.on()) {
            debug.log("sending GOAWAY " + goAway);
        }

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2083:

> 2081:                         ", GOAWAY sent=" + goAwaySent.get();
> 2082:                 debug.log("Closing connection (" + stateStr + ") due to: " + tc);
> 2083:             }

The message logged for debug is sufficiently different from the one logged with Log that we should consider actually logging both without fearing the repetition.
Either that, or consider logging the same message in both cases, in which case the else could stay.

Suggestion:

            if (Log.errors()) {
                Log.logError("Closing connection due to: {0}", tc);
            }
            if (debug.on()) {
                final String stateStr = "Abnormal close=" + tc.isAbnormalClose() +
                        ", has active streams=" + isActive() +
                        ", GOAWAY received=" + goAwayRecvd.get() +
                        ", GOAWAY sent=" + goAwaySent.get();
                debug.log("Closing connection (" + stateStr + ") due to: " + tc);
            }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2534576009
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2534589681

From duke at openjdk.org  Mon Nov 17 16:06:58 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 17 Nov 2025 16:06:58 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved
In-Reply-To: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
Message-ID: <-gHrXTabtAdyWZ_ZhCHyb79_bAwNMB79xC3SNTqKyLA=.4656bf45-2826-4fdc-83db-fae25cf1bf7a@github.com>

On Mon, 15 Sep 2025 02:50:27 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.

Most excellent, thank you for your hard work and attention

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3542658147

From vyazici at openjdk.org  Mon Nov 17 16:06:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 17 Nov 2025 16:06:58 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved
In-Reply-To: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
Message-ID: <a04ohaKYopF5g5CT22BWDi6LZU0EK8NslR9_3aV831Y=.69b24329-43b0-4342-b3a0-2e7f290da86c@github.com>

On Mon, 15 Sep 2025 02:50:27 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.

Inspired from your changes, I've put together [this patch](https://github.com/user-attachments/files/23579262/headerNormalize.patch) containing following changes:

- Ventilate and document `Headers::normalize`
- Convert the method to `private static`
- Extend tests
- Add a benchmark

@SentryMan, unless you have remarks/objections, would you mind applying the patch, please?

For the record, we internally discussed two other related issues:

- The inconsistency between `Headers::getFirst` and `Headers::keySet::get`
- Switching from the first-letter-in-upper-case normalization form to all-lower-case ? This would ease the cognitive load, simplify the implementation (i.e. maintainability & efficiency gains), match the RFC recommendations:
  
  > "Field names MUST be converted to lowercase when constructing an HTTP/2 message." ? [RFC 9113: HTTP/2 > 8. Expressing HTTP Semantics in HTTP/2 > 8.2. HTTP Fields](https://www.rfc-editor.org/rfc/rfc9113#section-8.2)
  
  But this might break certain applications relying on the existing behaviour.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3540930536

From duke at openjdk.org  Mon Nov 17 16:06:55 2025
From: duke at openjdk.org (Josiah Noel)
Date: Mon, 17 Nov 2025 16:06:55 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
Message-ID: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>

> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.

Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:

  patch

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27276/files
  - new: https://git.openjdk.org/jdk/pull/27276/files/3ee11198..6b9eb4f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27276&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27276&range=00-01

  Stats: 177 lines in 3 files changed: 150 ins; 7 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27276.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27276/head:pull/27276

PR: https://git.openjdk.org/jdk/pull/27276

From bpb at openjdk.org  Mon Nov 17 20:26:57 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 17 Nov 2025 20:26:57 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v18]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <IuoxMcptxkzLxVzHpPhRRztqRKzIqN4Onu1TyfK5bis=.ebcf5b34-c7f1-4f36-aa2a-40ed7e8516a3@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 8 more: https://git.openjdk.org/jdk/compare/9ec773ad...75555455

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=17
  Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From vyazici at openjdk.org  Tue Nov 18 08:06:05 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 18 Nov 2025 08:06:05 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <-dple3e7yuPGTVMEqeIGn3A9fxDQ16e7_di_It4Tx9w=.2b2ce899-bd5d-4e07-907a-92e751af325b@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

Verified that Tiers 1-2 is clear on 6b9eb4f0ec2.

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27276#pullrequestreview-3476024307

From vyazici at openjdk.org  Tue Nov 18 12:42:15 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 18 Nov 2025 12:42:15 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <zqjyTNvtnU3Uk9xzie8p_ZP3NT493K26tcqLcMk28h8=.2118b249-f70f-4afa-86bd-3946724ecf76@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

Attaching the benchmark results for the record:


$ git merge upstream/master
$ make run-test TEST="micro:HeaderNormalization" MICRO="OPTIONS=-prof gc
Benchmark                                            (key)  Mode  Cnt     Score     Error   Units
HeaderNormalization.n25                     Accept-charset  avgt   15    12.673 ?   0.248   ns/op
HeaderNormalization.n25:gc.alloc.rate       Accept-charset  avgt   15  7826.300 ? 154.610  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  Accept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            Accept-charset  avgt   15    82.000            counts
HeaderNormalization.n25:gc.time             Accept-charset  avgt   15    61.000                ms
HeaderNormalization.n25                     accept-charset  avgt   15    12.728 ?   0.277   ns/op
HeaderNormalization.n25:gc.alloc.rate       accept-charset  avgt   15  7793.079 ? 170.106  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  accept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            accept-charset  avgt   15    87.000            counts
HeaderNormalization.n25:gc.time             accept-charset  avgt   15    62.000                ms
HeaderNormalization.n25                     Accept-Charset  avgt   15    12.491 ?   0.273   ns/op
HeaderNormalization.n25:gc.alloc.rate       Accept-Charset  avgt   15  7940.943 ? 173.267  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  Accept-Charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            Accept-Charset  avgt   15    86.000            counts
HeaderNormalization.n25:gc.time             Accept-Charset  avgt   15    67.000                ms
HeaderNormalization.n25                     ACCEPT-CHARSET  avgt   15    12.783 ?   0.222   ns/op
HeaderNormalization.n25:gc.alloc.rate       ACCEPT-CHARSET  avgt   15  7758.515 ? 132.436  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  ACCEPT-CHARSET  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            ACCEPT-CHARSET  avgt   15    91.000            counts
HeaderNormalization.n25:gc.time             ACCEPT-CHARSET  avgt   15    64.000                ms
HeaderNormalization.n26                     Accept-charset  avgt   15     7.871 ?   0.056   ns/op
HeaderNormalization.n26:gc.alloc.rate       Accept-charset  avgt   15     0.007 ?   0.001  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  Accept-charset  avgt   15    ? 10??              B/op
HeaderNormalization.n26:gc.count            Accept-charset  avgt   15       ? 0            counts
HeaderNormalization.n26                     accept-charset  avgt   15    12.864 ?   0.225   ns/op
HeaderNormalization.n26:gc.alloc.rate       accept-charset  avgt   15  7709.843 ? 136.491  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  accept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n26:gc.count            accept-charset  avgt   15    81.000            counts
HeaderNormalization.n26:gc.time             accept-charset  avgt   15    60.000                ms
HeaderNormalization.n26                     Accept-Charset  avgt   15    15.299 ?   0.407   ns/op
HeaderNormalization.n26:gc.alloc.rate       Accept-Charset  avgt   15  6485.181 ? 174.316  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  Accept-Charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n26:gc.count            Accept-Charset  avgt   15   120.000            counts
HeaderNormalization.n26:gc.time             Accept-Charset  avgt   15    77.000                ms
HeaderNormalization.n26                     ACCEPT-CHARSET  avgt   15    13.601 ?   0.347   ns/op
HeaderNormalization.n26:gc.alloc.rate       ACCEPT-CHARSET  avgt   15  7294.108 ? 185.918  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  ACCEPT-CHARSET  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n26:gc.count            ACCEPT-CHARSET  avgt   15   117.000            counts
HeaderNormalization.n26:gc.time             ACCEPT-CHARSET  avgt   15    78.000                ms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3547472395

From duke at openjdk.org  Tue Nov 18 14:21:42 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Tue, 18 Nov 2025 14:21:42 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v4]
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <ZKXGY5Wz3y0NQr7CGAK8IKkyYF5k8jKwcWJqM_pb9X0=.5265046a-73b4-4026-b362-64c41ffa509d@github.com>

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Oumaiyma Intissar has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8367049: URL.openConnection throws StringIndexOutOfBoundsException in avm mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27896/files
  - new: https://git.openjdk.org/jdk/pull/27896/files/17d1c7a7..409b886a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From dfuchs at openjdk.org  Tue Nov 18 14:30:09 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 14:30:09 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <o6nH9sWVURuzcFMDESnyFOjbXWS9LFIVsrIOoWwwx54=.e5e99966-fbda-4193-b60f-cda0de207a66@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

LGTM. I also ran some tests and they all came back green. Thanks for this nice improvement @SentryMan and @vy !

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27276#pullrequestreview-3478107611

From michaelm at openjdk.org  Tue Nov 18 14:46:39 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 18 Nov 2025 14:46:39 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 157:

> 155:                 throw new IllegalArgumentException("illegal character in key at index " + i);
> 156:             }
> 157:             cs[0] = (char) (c - o);

There's an assumption here that because of the test at line 135 then `c` must be a lower case letter. But, it could in principle be any `tchar` (token character) which includes digits and vchars other than lower case letters. We should check `if (c >= 'a' && c <= 'z')`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2538466371

From dfuchs at openjdk.org  Tue Nov 18 14:46:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 14:46:40 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
 <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
Message-ID: <Fj-zMWuHooagMqSkDrYdMk2ZGKnHaT_p-DlwfH7IhNw=.79fe5bc2-3fd6-4264-baa4-5ee56c892e4b@github.com>

On Tue, 18 Nov 2025 14:41:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   patch
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 157:
> 
>> 155:                 throw new IllegalArgumentException("illegal character in key at index " + i);
>> 156:             }
>> 157:             cs[0] = (char) (c - o);
> 
> There's an assumption here that because of the test at line 135 then `c` must be a lower case letter. But, it could in principle be any `tchar` (token character) which includes digits and vchars other than lower case letters. We should check `if (c >= 'a' && c <= 'z')`

Ah! Good catch Michael!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2538473378

From dfuchs at openjdk.org  Tue Nov 18 14:51:42 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 14:51:42 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <WSw4OsCvidzCJtyPnsxPiTCu93QR_DZRZG6XYotSGpg=.725a1567-2f62-4bef-8b0e-4f43f6fb06d8@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

Changes requested by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27276#pullrequestreview-3478203139

From dfuchs at openjdk.org  Tue Nov 18 14:51:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 14:51:44 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Fj-zMWuHooagMqSkDrYdMk2ZGKnHaT_p-DlwfH7IhNw=.79fe5bc2-3fd6-4264-baa4-5ee56c892e4b@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
 <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
 <Fj-zMWuHooagMqSkDrYdMk2ZGKnHaT_p-DlwfH7IhNw=.79fe5bc2-3fd6-4264-baa4-5ee56c892e4b@github.com>
Message-ID: <PwIljR8J5flsm1zq77Ogh3Hy7XpULj5T3lW9YlFpLs0=.8850248c-89c9-4c41-9d12-5361edf2f72b@github.com>

On Tue, 18 Nov 2025 14:43:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 157:
>> 
>>> 155:                 throw new IllegalArgumentException("illegal character in key at index " + i);
>>> 156:             }
>>> 157:             cs[0] = (char) (c - o);
>> 
>> There's an assumption here that because of the test at line 135 then `c` must be a lower case letter. But, it could in principle be any `tchar` (token character) which includes digits and vchars other than lower case letters. We should check `if (c >= 'a' && c <= 'z')`
>
> Ah! Good catch Michael!

@SentryMan can a test case be added for that - using e.g. a field name like "2xyz" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2538490751

From dfuchs at openjdk.org  Tue Nov 18 14:54:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 18 Nov 2025 14:54:48 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v4]
In-Reply-To: <ZKXGY5Wz3y0NQr7CGAK8IKkyYF5k8jKwcWJqM_pb9X0=.5265046a-73b4-4026-b362-64c41ffa509d@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <ZKXGY5Wz3y0NQr7CGAK8IKkyYF5k8jKwcWJqM_pb9X0=.5265046a-73b4-4026-b362-64c41ffa509d@github.com>
Message-ID: <GyFbYh9du-6y-bw4lxsRDz_BiV-7Vprm6HkrTGq1uEw=.626c978a-330e-46c9-9bf9-0daf88822c12@github.com>

On Tue, 18 Nov 2025 14:21:42 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8367049: URL.openConnection throws StringIndexOutOfBoundsException in avm mode

LGTM - please run tier2 before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27896#pullrequestreview-3478223282

From vyazici at openjdk.org  Tue Nov 18 15:48:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 18 Nov 2025 15:48:45 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
 <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
Message-ID: <y1XuF2D73vbduCcsujaQfw_1BQwLsCsxcBEKayHLhg4=.bef5b3c2-8a67-4cbe-8baa-e53b481f6082@github.com>

On Tue, 18 Nov 2025 14:41:33 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   patch
>
> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 157:
> 
>> 155:                 throw new IllegalArgumentException("illegal character in key at index " + i);
>> 156:             }
>> 157:             cs[0] = (char) (c - o);
> 
> There's an assumption here that because of the test at line 135 then `c` must be a lower case letter. But, it could in principle be any `tchar` (token character) which includes digits and vchars other than lower case letters. We should check `if (c >= 'a' && c <= 'z')`

@Michael-Mc-Mahon, very good (embarrassing :facepalm:) catch!

@dfuch, I guess `httpserver/HeadersTest.java` needs a serious overhaul against these kind of normalization edge cases. I will try tackling this tomorrow (CET). @SentryMan, let me know if you prefer picking this up yourself.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2538711370

From vyazici at openjdk.org  Tue Nov 18 16:02:45 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 18 Nov 2025 16:02:45 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <dErnHfZuFWlr8jQYgPzrkuED4CcKm-5qm_RYAcJu3xQ=.4bd8ba72-2b63-4a38-bf64-735ec921376f@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 135:

> 133:         int i = 0;
> 134:         char c = key.charAt(i);
> 135:         if (c >= 'A' && c <= 'Z') {

This check is wrong too ? valid non-lower-case letters are ignored ? and I'm the one to blame. I will take care of this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2538763852

From michaelm at openjdk.org  Tue Nov 18 16:08:01 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 18 Nov 2025 16:08:01 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v4]
In-Reply-To: <ZKXGY5Wz3y0NQr7CGAK8IKkyYF5k8jKwcWJqM_pb9X0=.5265046a-73b4-4026-b362-64c41ffa509d@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <ZKXGY5Wz3y0NQr7CGAK8IKkyYF5k8jKwcWJqM_pb9X0=.5265046a-73b4-4026-b362-64c41ffa509d@github.com>
Message-ID: <VjlzaSjqX0BmqQtYgYUn8kD1tOSwtNnJVyL_9gNTvBM=.8fb4f696-ae19-4b60-b1c1-a30eea6cde99@github.com>

On Tue, 18 Nov 2025 14:21:42 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8367049: URL.openConnection throws StringIndexOutOfBoundsException in avm mode

Looks fine.

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27896#pullrequestreview-3478581338

From jpai at openjdk.org  Wed Nov 19 07:46:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 07:46:37 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v6]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <xcZdr4CbLseIeGg4VIw5Pmy3tEY3tu_98IXRddJyrOM=.a4975221-7726-4963-850c-37e769ae72f2@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:

 - rename method
 - remove unneeded method
 - logging and javadoc comment fixes
 - merge latest from master branch
 - update test to use h2c HTTP/2 server
 - fix typo in test code comment
 - trivial debug log check change
 - rename isErroneousClose() to isAbnormalClose()
 - stackless instance for idle timed out NoError
 - Volkan's suggestion - log message improvement
 - ... and 9 more: https://git.openjdk.org/jdk/compare/098155bd...c554a521

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/f4ed10d9..c554a521

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=04-05

  Stats: 20731 lines in 292 files changed: 12805 ins; 5674 del; 2252 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Wed Nov 19 10:03:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:03:23 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <6bgwf-dekiwGBoVzArBjSXuihX1bvFbbe2RQhbTeJJI=.7e351b8a-5698-412c-a2ba-33c9eccad2cc@github.com>

On Wed, 12 Nov 2025 10:47:30 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 102:
> 
>> 100:     private static Field openConnections; // Set<> jdk.internal.net.http.HttpClientImpl#openedConnections
>> 101: 
>> 102:     private static SSLContext sslContext;
> 
> Is SSL a necessity for this test? Put another way, does SSL play a role in the connection leakage?

I've now updated the PR to use regular HTTP/2 server without TLS. TLS doesn't play a role in this issue.

> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 195:
> 
>> 193:     // using reflection, return the jdk.internal.net.http.HttpClientImpl instance held
>> 194:     // by the given client
>> 195:     private static Object reflectHttpClientImplInstance(final HttpClient client) throws Exception {
> 
> Instead, you can use `Http3ConnectionAccess::impl` too.

Hello Volkan, I wasn't aware of this test class and it looks like it has been minimally used. The `impl()` method on that test class is a package private method which then means that I will have to include a `package` statement to this new test itself. Or change the `impl()` method to `public`. For now I decided to not fiddle with it. If you would like me to pursue it further in this PR, let me know and I can do that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541325409
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541323780

From jpai at openjdk.org  Wed Nov 19 10:11:33 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:11:33 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <QM-1UJw4VJgXFqOdkdJ8gr6D7vR1wRChtIvg2C_d2yQ=.e48f8573-7571-4a00-a479-349df0e7c870@github.com>

On Wed, 12 Nov 2025 10:14:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - mark jdk.internal.net.http.Http2Connection as Closable
>>  - reduce number of concurrent requests
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 889:
> 
>> 887:      * If the connection hasn't yet been terminated then this method returns an empty Optional.
>> 888:      */
>> 889:     final Optional<IOException> getTerminationException() {
> 
> There is one place this method is used and it does `getTerminationException().orElse(null)`. I guess we can drop the `Optional` ceremony.

I removed this method in the latest update to this PR.

> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2134:
> 
>> 2132:                 // that way when Http2Connection.isOpen() returns false in that situation, then this
>> 2133:                 // getTerminationCause() will return a termination cause.
>> 2134:                 terminate(Http2TerminationCause.forException(new IOException("channel is not open")));
> 
> Terminating the connection in a getter doesn't feel all right. Would you mind elaborating on the rationale, the absence of a better alternative, please?

We spoke about this detail offline and I decided to rename the method to `determineTerminationCause()` instead of calling it `getTerminationCause()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541343245
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541336328

From jpai at openjdk.org  Wed Nov 19 10:11:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:11:37 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v5]
In-Reply-To: <EuGb3Tx482T5M9VxTq2-TFu2B1lJtnriN9CHDMU7SSk=.ca24f010-b4a5-4821-9060-01dce2165202@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9UZT300xVhV88-9qnfOUiw5j3HCfqe5c3HJgz-j4p8c=.96562cab-0b1d-4581-80c5-ad215a7e104b@github.com>
 <EuGb3Tx482T5M9VxTq2-TFu2B1lJtnriN9CHDMU7SSk=.ca24f010-b4a5-4821-9060-01dce2165202@github.com>
Message-ID: <gh75HBMzLl9lS5hENL6lqvYlEru3rvicT5I0YU5Eilg=.93a1d83e-66b5-4398-840c-40f6b481a5e3@github.com>

On Mon, 17 Nov 2025 15:40:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo in test code comment
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2022:
> 
>> 2020:         if (debug.on()) {
>> 2021:             debug.log("sending GOAWAY " + goAway);
>> 2022:         }
> 
> Suggestion:
> 
>         if (Log.trace()) {
>             Log.logTrace("{0} sending GOAWAY {1}", connection, goAway);
>         } else if (debug.on()) {
>             debug.log("sending GOAWAY " + goAway);
>         }

Done, updated the PR with this change.

> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2083:
> 
>> 2081:                         ", GOAWAY sent=" + goAwaySent.get();
>> 2082:                 debug.log("Closing connection (" + stateStr + ") due to: " + tc);
>> 2083:             }
> 
> The message logged for debug is sufficiently different from the one logged with Log that we should consider actually logging both without fearing the repetition.
> Either that, or consider logging the same message in both cases, in which case the else could stay.
> 
> Suggestion:
> 
>             if (Log.errors()) {
>                 Log.logError("Closing connection due to: {0}", tc);
>             }
>             if (debug.on()) {
>                 final String stateStr = "Abnormal close=" + tc.isAbnormalClose() +
>                         ", has active streams=" + isActive() +
>                         ", GOAWAY received=" + goAwayRecvd.get() +
>                         ", GOAWAY sent=" + goAwaySent.get();
>                 debug.log("Closing connection (" + stateStr + ") due to: " + tc);
>             }

I decided to use the same level of information in both these logs. While at it, it felt odd to use `Log.logError()` to log a connection being closed, but it looks like we don't have a more specific/appropriate log method for this case. So I let it stay `Log.logError()` for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541345597
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541351458

From michaelm at openjdk.org  Wed Nov 19 10:12:05 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 19 Nov 2025 10:12:05 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <y1XuF2D73vbduCcsujaQfw_1BQwLsCsxcBEKayHLhg4=.bef5b3c2-8a67-4cbe-8baa-e53b481f6082@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
 <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
 <y1XuF2D73vbduCcsujaQfw_1BQwLsCsxcBEKayHLhg4=.bef5b3c2-8a67-4cbe-8baa-e53b481f6082@github.com>
Message-ID: <C9t_ORrRLqUQ5rl8KPTl54N3Vtq3YFGmn17RG8IbokY=.67fd2c21-a3bc-4b07-8f10-12b03a4f804a@github.com>

On Tue, 18 Nov 2025 15:45:20 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/jdk.httpserver/share/classes/com/sun/net/httpserver/Headers.java line 157:
>> 
>>> 155:                 throw new IllegalArgumentException("illegal character in key at index " + i);
>>> 156:             }
>>> 157:             cs[0] = (char) (c - o);
>> 
>> There's an assumption here that because of the test at line 135 then `c` must be a lower case letter. But, it could in principle be any `tchar` (token character) which includes digits and vchars other than lower case letters. We should check `if (c >= 'a' && c <= 'z')`
>
> @Michael-Mc-Mahon, very good (embarrassing :facepalm:) catch!
> 
> @dfuch, I guess `httpserver/HeadersTest.java` needs a serious overhaul against these kind of normalization edge cases. I will try tackling this tomorrow (CET). @SentryMan, let me know if you prefer picking this up yourself.

The other issue you found at line 135 raises the question to _how_ strings that don't start with a letter are normalized? (A) Do we only ever put the first character as uppercase (if it's a letter)? Or (B) do we always put the first letter in a string in uppercase, wherever it appears in the string? 

Looks like the current behavior is (A) and we should stick with that, from the point of view of new tests. So, `2xyz` would be normalized as `2xyz`, but `xyz2` would be normalized as `Xyz2`. Does that make sense?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2541344708

From jpai at openjdk.org  Wed Nov 19 10:18:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:18:27 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <bVC7sW7JDEX68FjGdEbUj6Swan95ZbQA8gkrTzD1YyE=.1ff1a804-b2e5-47ac-be7d-f2400ce020b4@github.com>

On Wed, 12 Nov 2025 11:01:07 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Verify secondary request bursts always reuse the pooled connection,

Unless we set the pool idle timeout to a very high value, it's not always possible to guarantee that the secondary burst will use a pooled connection. And it's OK if the secondary burst doesn't use a pooled connection (if one isn't available). So testing that here, I think, isn't necessary.

> Remember that, as reported in the associated ticket, the secondary bursts were causing the orphan connection pile up.

The secondary burst creating a fresh set of connections will continue to happen if there isn't any pooled connection. The fix in this PR won't address this (unless like I noted we increase the pool timeout to a very high value to force the connection to stay around, even on "slow" CI machines). Our previous discussion around the high connection creation for bursty request was that we would review that code and very likely enhance it in the coming days to improve that to reduce the connection creation. So I think any tests verifying that would be better done as part of that exercise.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541373458

From jpai at openjdk.org  Wed Nov 19 10:24:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:24:50 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v6]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <FEy8_VvjkS0FgTyja9yrM6kG_rTtKWQOpV-0Pq7mW8g=.e321ec4b-983b-47cc-a8cd-1954e06d2462@github.com>

On Wed, 12 Nov 2025 09:23:56 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - rename method
>>  - remove unneeded method
>>  - logging and javadoc comment fixes
>>  - merge latest from master branch
>>  - update test to use h2c HTTP/2 server
>>  - fix typo in test code comment
>>  - trivial debug log check change
>>  - rename isErroneousClose() to isAbnormalClose()
>>  - stackless instance for idle timed out NoError
>>  - Volkan's suggestion - log message improvement
>>  - ... and 9 more: https://git.openjdk.org/jdk/compare/832ec6d1...c554a521
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 35:
> 
>> 33: 
>> 34: /**
>> 35:  * Termination cause for a {@linkplain Http2Connection HTTP/2 connection}
> 
> Suggestion:
> 
>  * Termination cause for an {@linkplain Http2Connection HTTP/2 connection}

Done

> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 71:
> 
>> 69:      * Returns the IOException that is considered the cause of the connection termination.
>> 70:      * Even a normal {@linkplain #isErroneousClose() non-erroneous} termination will have
>> 71:      * a IOException associated with it, so this method will always return a non-null instance.
> 
> Suggestion:
> 
>      * Returns the {@link IOException} that is considered the cause of the connection termination.
>      * Even a normal {@linkplain #isErroneousClose() non-erroneous} termination will have
>      * an {@code IOException} associated with it, so this method will always return a non-null instance.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541388804
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541389341

From jpai at openjdk.org  Wed Nov 19 10:33:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:33:46 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  use Utils.toIOException()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/c554a521..623547d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Wed Nov 19 10:42:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:42:44 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
Message-ID: <zVm1cjXmvEqewh2_lqJrDyHb0i-t0fOStRR4gBO4uDE=.7a38c945-b129-4f67-9897-f7e2a14bfbfd@github.com>

On Wed, 19 Nov 2025 10:33:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Utils.toIOException()

I've updated the PR to address several of the review comments and I don't have any more planned changes to this PR, unless of course for any new review comments. CI tier run is currently in progress with these changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28233#issuecomment-3552000926

From jpai at openjdk.org  Wed Nov 19 10:42:45 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 10:42:45 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
Message-ID: <rdJWx44Sht-xQaZT2cAKKy5udmNqHfcGNCNT99C27qA=.b6ea3da3-08b3-477e-a6cd-fe88acad2ca2@github.com>

On Wed, 12 Nov 2025 09:33:58 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use Utils.toIOException()
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 176:
> 
>> 174:         } else {
>> 175:             return new IOException(original);
>> 176:         }
> 
> I presume we don't need to peel off any `CompletionException` and/or `ExecutionException`, right?

This is a good point. Given the nature of this method, which can/must get called for terminating the connection for any failure, it can't be ruled out that the `original` exception is either a `CompletionException` or `ExecutionException`. The call sites shouldn't be bothered with doing those checks, so I've updated the PR to use the pre-existing `Utils.toIOException(original)` here. I have triggered a new CI run with these changes (and I don't except it to cause issues).

Separately, I will consider whether we need to do this same thing in the HTTP3 connection termination cause as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541445265

From eirbjo at openjdk.org  Wed Nov 19 11:33:39 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 19 Nov 2025 11:33:39 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
Message-ID: <_WgrY4fVQnBoz4aEK_ZbIpdEKOqAg2ubHcjKvyujkCk=.440fefc3-eead-4cd6-8b6d-d693be2e832c@github.com>

On Mon, 17 Nov 2025 16:06:55 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch

I have not reviewed the code, just observing that the issue title here is not very descriptive. (Just about any interesting method in the JDK can be "improved" one way or the other)

Consider something more specific, like: "Reduce allocation in x.y.z", "Improve performance of x.y.z"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3552196024

From vyazici at openjdk.org  Wed Nov 19 11:50:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 19 Nov 2025 11:50:36 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved
In-Reply-To: <-gHrXTabtAdyWZ_ZhCHyb79_bAwNMB79xC3SNTqKyLA=.4656bf45-2826-4fdc-83db-fae25cf1bf7a@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <-gHrXTabtAdyWZ_ZhCHyb79_bAwNMB79xC3SNTqKyLA=.4656bf45-2826-4fdc-83db-fae25cf1bf7a@github.com>
Message-ID: <qsVQbkA0skvr9kqwuBnz5fFn3k6Au6LEwqWdaUx7yDU=.e39f1261-271a-4ef0-aae6-0b02dbf124df@github.com>

On Mon, 17 Nov 2025 16:02:41 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Most excellent, thank you for your hard work and attention

@SentryMan, I've (hopefully) fixed the issue, added more tests, and a new benchmark case. Would you mind reviewing and applying [this patch](https://github.com/user-attachments/files/23626853/headerNormalize-v2.patch), please?

I've updated the JBS issue title as @eirbjo suggested. @SentryMan, could you also rename the PR title to match it, please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3552257748

From dfuchs at openjdk.org  Wed Nov 19 12:33:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Nov 2025 12:33:26 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v2]
In-Reply-To: <C9t_ORrRLqUQ5rl8KPTl54N3Vtq3YFGmn17RG8IbokY=.67fd2c21-a3bc-4b07-8f10-12b03a4f804a@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
 <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
 <y1XuF2D73vbduCcsujaQfw_1BQwLsCsxcBEKayHLhg4=.bef5b3c2-8a67-4cbe-8baa-e53b481f6082@github.com>
 <C9t_ORrRLqUQ5rl8KPTl54N3Vtq3YFGmn17RG8IbokY=.67fd2c21-a3bc-4b07-8f10-12b03a4f804a@github.com>
Message-ID: <G-Xjwhwz3g1pDgPZIgZZfmBn-Cn60ia5Bo84DFjiFL4=.965e97e4-2ae8-4808-9b97-a69e01c75c03@github.com>

On Wed, 19 Nov 2025 10:06:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> @Michael-Mc-Mahon, very good (embarrassing :facepalm:) catch!
>> 
>> @dfuch, I guess `httpserver/HeadersTest.java` needs a serious overhaul against these kind of normalization edge cases. I will try tackling this tomorrow (CET). @SentryMan, let me know if you prefer picking this up yourself.
>
> The other issue you found at line 135 raises the question to _how_ strings that don't start with a letter are normalized? (A) Do we only ever put the first character as uppercase (if it's a letter)? Or (B) do we always put the first letter in a string in uppercase, wherever it appears in the string? 
> 
> Looks like the current behavior is (A) and we should stick with that, from the point of view of new tests. So, `2xyz` would be normalized as `2xyz`, but `xyz2` would be normalized as `Xyz2`. Does that make sense?

That's what I would expect yes. 

2xyz -> 2xyz
2xyZ -> 2xyz
xyz2 -> Xyz2
Xy2Z -> Xy2z
xYZ2 -> Xyz2

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2541811987

From dfuchs at openjdk.org  Wed Nov 19 13:13:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Nov 2025 13:13:08 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
Message-ID: <iX8hJtiGZr9RJFoWKxCS3tB1KCwXX4OvCzBFoHWEkVM=.7636c4a4-0302-4929-a096-c55ffa711269@github.com>

On Wed, 19 Nov 2025 10:33:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Utils.toIOException()

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 38:

> 36: import java.net.http.HttpHeaders;
> 37: import java.nio.ByteBuffer;
> 38: import java.nio.channels.NetworkChannel;

Unless I'm mistaken this import is not needed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541897486

From dfuchs at openjdk.org  Wed Nov 19 13:13:10 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Nov 2025 13:13:10 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <6bgwf-dekiwGBoVzArBjSXuihX1bvFbbe2RQhbTeJJI=.7e351b8a-5698-412c-a2ba-33c9eccad2cc@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
 <6bgwf-dekiwGBoVzArBjSXuihX1bvFbbe2RQhbTeJJI=.7e351b8a-5698-412c-a2ba-33c9eccad2cc@github.com>
Message-ID: <MbeJu73ms2Ch8VhzAjyIxQ2HukJPORGB6u8lsNr8olE=.d6bc8889-6eba-4e0a-8152-2c2dd578c448@github.com>

On Wed, 19 Nov 2025 09:59:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 195:
>> 
>>> 193:     // using reflection, return the jdk.internal.net.http.HttpClientImpl instance held
>>> 194:     // by the given client
>>> 195:     private static Object reflectHttpClientImplInstance(final HttpClient client) throws Exception {
>> 
>> Instead, you can use `Http3ConnectionAccess::impl` too.
>
> Hello Volkan, I wasn't aware of this test class and it looks like it has been minimally used. The `impl()` method on that test class is a package private method which then means that I will have to include a `package` statement to this new test itself. Or change the `impl()` method to `public`. For now I decided to not fiddle with it. If you would like me to pursue it further in this PR, let me know and I can do that.

The idea is to use the `access` library to inject classes in (internal) packages when you need access to package protected APIs. That would not work for anything private - unless the injected class uses Lookup.privateLookupIn() to access the target class private APIs. The advantage is that it avoids to redefine the `@modules` - you don't need the additional `+open` when the accessor class (a public class) is already injected in the package

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2541952047

From jpai at openjdk.org  Wed Nov 19 13:35:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 13:35:01 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <iX8hJtiGZr9RJFoWKxCS3tB1KCwXX4OvCzBFoHWEkVM=.7636c4a4-0302-4929-a096-c55ffa711269@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
 <iX8hJtiGZr9RJFoWKxCS3tB1KCwXX4OvCzBFoHWEkVM=.7636c4a4-0302-4929-a096-c55ffa711269@github.com>
Message-ID: <kZPA5c0BlimNBOUHb4hEZaCLg5NDAfYEujI_uQaUTuE=.0e3f2415-8e26-464b-b6cc-50a216d65291@github.com>

On Wed, 19 Nov 2025 12:58:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use Utils.toIOException()
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 38:
> 
>> 36: import java.net.http.HttpHeaders;
>> 37: import java.nio.ByteBuffer;
>> 38: import java.nio.channels.NetworkChannel;
> 
> Unless I'm mistaken this import is not needed?

The javadoc comment I added to `Http2Connection.isOpen()` uses `{@linkplain NetworkChannel#isOpen() channel is open}`. It looks like the IDE added it for that reason. I'm going to see if removing the import will cause any build failures in any places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2542027764

From dfuchs at openjdk.org  Wed Nov 19 13:45:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Nov 2025 13:45:47 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <kZPA5c0BlimNBOUHb4hEZaCLg5NDAfYEujI_uQaUTuE=.0e3f2415-8e26-464b-b6cc-50a216d65291@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
 <iX8hJtiGZr9RJFoWKxCS3tB1KCwXX4OvCzBFoHWEkVM=.7636c4a4-0302-4929-a096-c55ffa711269@github.com>
 <kZPA5c0BlimNBOUHb4hEZaCLg5NDAfYEujI_uQaUTuE=.0e3f2415-8e26-464b-b6cc-50a216d65291@github.com>
Message-ID: <CNJn7focxokFBgckosAhVBDDv8kl4-4VQgytUHVKAFs=.aa43762a-55ee-4e25-bfa1-f037bc242cca@github.com>

On Wed, 19 Nov 2025 13:32:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 38:
>> 
>>> 36: import java.net.http.HttpHeaders;
>>> 37: import java.nio.ByteBuffer;
>>> 38: import java.nio.channels.NetworkChannel;
>> 
>> Unless I'm mistaken this import is not needed?
>
> The javadoc comment I added to `Http2Connection.isOpen()` uses `{@linkplain NetworkChannel#isOpen() channel is open}`. It looks like the IDE added it for that reason. I'm going to see if removing the import will cause any build failures in any places.

Ah - OK - I missed that - the import is needed then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2542046983

From duke at openjdk.org  Wed Nov 19 14:09:09 2025
From: duke at openjdk.org (Josiah Noel)
Date: Wed, 19 Nov 2025 14:09:09 GMT
Subject: RFR: 8347167: Implementation in
 com.sun.net.httpserver.Headers.normalize() can be improved [v3]
In-Reply-To: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
Message-ID: <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>

> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.

Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:

  patch 2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27276/files
  - new: https://git.openjdk.org/jdk/pull/27276/files/6b9eb4f0..1a849f44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27276&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27276&range=01-02

  Stats: 89 lines in 3 files changed: 84 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27276.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27276/head:pull/27276

PR: https://git.openjdk.org/jdk/pull/27276

From jpai at openjdk.org  Wed Nov 19 15:38:56 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 15:38:56 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v8]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <Cb4534BAUGaCUpn3Xz1e_xTFAYVYlCIHzvUNI0OkCWs=.fa74ec55-0c51-4404-9ee6-f8896c6a94f4@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Remove import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/623547d1..f53bf478

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Wed Nov 19 15:38:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 19 Nov 2025 15:38:57 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v7]
In-Reply-To: <CNJn7focxokFBgckosAhVBDDv8kl4-4VQgytUHVKAFs=.aa43762a-55ee-4e25-bfa1-f037bc242cca@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <nOyYJyvjitHgIe4hCdyRXctpFX4B26N6Xlkk2qfJMEU=.3112c851-0737-4343-bd9f-fb47a8fb638b@github.com>
 <iX8hJtiGZr9RJFoWKxCS3tB1KCwXX4OvCzBFoHWEkVM=.7636c4a4-0302-4929-a096-c55ffa711269@github.com>
 <kZPA5c0BlimNBOUHb4hEZaCLg5NDAfYEujI_uQaUTuE=.0e3f2415-8e26-464b-b6cc-50a216d65291@github.com>
 <CNJn7focxokFBgckosAhVBDDv8kl4-4VQgytUHVKAFs=.aa43762a-55ee-4e25-bfa1-f037bc242cca@github.com>
Message-ID: <Efm1HYxeshCt9EtOZ1CMtC_1qYTCiyvuFEvhRDJociI=.f5572fd2-3fd5-4415-a6bb-904cb7f9ec86@github.com>

On Wed, 19 Nov 2025 13:37:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> The javadoc comment I added to `Http2Connection.isOpen()` uses `{@linkplain NetworkChannel#isOpen() channel is open}`. It looks like the IDE added it for that reason. I'm going to see if removing the import will cause any build failures in any places.
>
> Ah - OK - I missed that - the import is needed then.

I ran a local `make docs-image` and a CI build and tier1 testing with the import removed and they all passed. So I've updated this PR to remove that import.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2542542008

From dfuchs at openjdk.org  Wed Nov 19 16:18:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Nov 2025 16:18:39 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread
Message-ID: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>

Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
This should be transparent for users of the API. 
An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

-------------

Commit messages:
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

Changes: https://git.openjdk.org/jdk/pull/28395/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372159
  Stats: 290 lines in 8 files changed: 264 ins; 15 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

PR: https://git.openjdk.org/jdk/pull/28395

From dfuchs at openjdk.org  Wed Nov 19 19:03:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 19 Nov 2025 19:03:28 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v2]
In-Reply-To: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
Message-ID: <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>

> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to SelectorManager::shutdown

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28395/files
  - new: https://git.openjdk.org/jdk/pull/28395/files/a311e708..dd4acad7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=00-01

  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

PR: https://git.openjdk.org/jdk/pull/28395

From jpai at openjdk.org  Thu Nov 20 09:44:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 09:44:17 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v2]
In-Reply-To: <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>
Message-ID: <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>

On Wed, 19 Nov 2025 19:03:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
>> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
>> This should be transparent for users of the API. 
>> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to SelectorManager::shutdown

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 131:

> 129: 
> 130:     static final UseVTForSelector USE_VT_FOR_SELECTOR =
> 131:         Utils.useVTForSelector("jdk.internal.httpclient.tcp.selector.useVirtualThreads", "default");

Hello Daniel, I vaguely remember we discussed whether or not to use a value called "default" for this property. But I don't remember what we decided. Looking at this now, I am wondering whether we should just do something like:

System.getProperty("jdk.internal.httpclient.tcp.selector.useVirtualThreads", "true")

to keep it simple?

test/jdk/java/net/httpclient/ReferenceTracker.java line 393:

> 391:     }
> 392: 
> 393:     private boolean isSelectorManager(Thread t) {

The copyright year on this file will need an update.

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 145:

> 143:             throw new AssertionError("Unexpected null sslContext");
> 144:         }
> 145:         // create an H3 only server

The use of "H3" here looks like a typo.

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 175:

> 173:             final HttpRequest req1 = reqBuilder.copy().GET().build();
> 174:             System.out.println("\nIssuing request: " + req1);
> 175:             final HttpResponse<?> resp1 = client.send(req1, BodyHandlers.ofString());

Nit - this line and the other 3 send() lines could perhaps use `BodyHandlers.discarding()`? If you prefer to use `ofString()`, that's fine too - it wasn't clear to me if this was an oversight.

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 195:

> 193:     }
> 194: 
> 195:     private static void assertSelectorThread(HttpClient client) {

I think a comment on what this method checks would be useful for future.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545102282
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545125815
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545108417
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545116878
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545124094

From dfuchs at openjdk.org  Thu Nov 20 09:56:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 09:56:34 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v2]
In-Reply-To: <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>
 <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
Message-ID: <d_cCPaTxsnpoKfFvrP7hN2qsWgEPRih_rMy-NTyrUGc=.e72ffefe-a452-4ec8-9c96-9b90135592ab@github.com>

On Thu, 20 Nov 2025 09:37:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to SelectorManager::shutdown
>
> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 175:
> 
>> 173:             final HttpRequest req1 = reqBuilder.copy().GET().build();
>> 174:             System.out.println("\nIssuing request: " + req1);
>> 175:             final HttpResponse<?> resp1 = client.send(req1, BodyHandlers.ofString());
> 
> Nit - this line and the other 3 send() lines could perhaps use `BodyHandlers.discarding()`? If you prefer to use `ofString()`, that's fine too - it wasn't clear to me if this was an oversight.

If you look at the log you will see that there is an exception being logged by Log "errors" at the end of each method. The exception is "selector manager closed". At first I thought it was caused by using `BodyHandlers.discarding()` - which I suspected might return a result early and discard data in the background. 
This is why I changed all to ofString(). But the exception is still there. 
The exception is logged because the selector is closed before all connections have been closed.
Trying to fix that I stumbled on an another issue - [JDK-8372198](https://bugs.openjdk.org/browse/JDK-8372198) - so I decided to revert my attempted fix https://github.com/openjdk/jdk/pull/28395/commits/dd4acad7528f1c401cb7cd5f15a4074c1be53be1 and fix that later in a follow up. But I kept `ofString`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545188393

From dfuchs at openjdk.org  Thu Nov 20 10:03:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 10:03:39 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v2]
In-Reply-To: <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>
 <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
Message-ID: <XTcMZSjZCbBIUkC-qGWAFjGpLrajrNn-9hddl1Mpl5M=.a609c482-2b58-4587-a7d8-27fdefd81d68@github.com>

On Thu, 20 Nov 2025 09:33:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to SelectorManager::shutdown
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 131:
> 
>> 129: 
>> 130:     static final UseVTForSelector USE_VT_FOR_SELECTOR =
>> 131:         Utils.useVTForSelector("jdk.internal.httpclient.tcp.selector.useVirtualThreads", "default");
> 
> Hello Daniel, I vaguely remember we discussed whether or not to use a value called "default" for this property. But I don't remember what we decided. Looking at this now, I am wondering whether we should just do something like:
> 
> System.getProperty("jdk.internal.httpclient.tcp.selector.useVirtualThreads", "true")
> 
> to keep it simple?

For tcp we only need true/false - but for quic we have a default behavior which depends on the platform. I decided to keep "always/never/default" for both properties for consistency. Let me think about it. I am not sure if that change (true/false for quic too) should be made in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545212056

From dfuchs at openjdk.org  Thu Nov 20 10:11:30 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 10:11:30 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v3]
In-Reply-To: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
Message-ID: <_0inh4_f7vQXjg4MgipF4mJpXZaz4psgstT96H9oO9I=.d98f14cd-c3d4-4a59-a770-979becd961d8@github.com>

> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback on test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28395/files
  - new: https://git.openjdk.org/jdk/pull/28395/files/dd4acad7..bdc84659

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=01-02

  Stats: 22 lines in 2 files changed: 18 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

PR: https://git.openjdk.org/jdk/pull/28395

From dfuchs at openjdk.org  Thu Nov 20 10:11:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 10:11:32 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v2]
In-Reply-To: <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>
 <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
Message-ID: <wAVA7YsQi5KSz4-pqfOebeKiHKfnA_ntyqgJxtWOhZk=.ce313111-7d86-465d-83b1-2b9c3f40ae1e@github.com>

On Thu, 20 Nov 2025 09:39:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to SelectorManager::shutdown
>
> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 195:
> 
>> 193:     }
>> 194: 
>> 195:     private static void assertSelectorThread(HttpClient client) {
> 
> I think a comment on what this method checks would be useful for future.

Done. I also replicated this in the `H3QuicVTTest` from which this test was copied.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2545259103

From vyazici at openjdk.org  Thu Nov 20 10:12:19 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 20 Nov 2025 10:12:19 GMT
Subject: RFR: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize [v2]
In-Reply-To: <C9t_ORrRLqUQ5rl8KPTl54N3Vtq3YFGmn17RG8IbokY=.67fd2c21-a3bc-4b07-8f10-12b03a4f804a@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <Xk1pg9jxYhSurSIoPfkwaa5zA4gi-abrxFvuXSgKLZY=.dbd298d3-2211-4ab8-9220-b08f091ec296@github.com>
 <J3-ntssERARDJl-5pVucosLXX-roSxN1NFdLiuDsI5s=.6bb4ccbf-b536-49c1-88c6-cdc8c51f7f3b@github.com>
 <y1XuF2D73vbduCcsujaQfw_1BQwLsCsxcBEKayHLhg4=.bef5b3c2-8a67-4cbe-8baa-e53b481f6082@github.com>
 <C9t_ORrRLqUQ5rl8KPTl54N3Vtq3YFGmn17RG8IbokY=.67fd2c21-a3bc-4b07-8f10-12b03a4f804a@github.com>
Message-ID: <PX47N8tr4ItTU4BmCC7F6vBJ0-yCwlnxiII2H2mTn-g=.cb4374e6-d415-469f-b48e-4e70dced8b13@github.com>

On Wed, 19 Nov 2025 10:06:10 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> @Michael-Mc-Mahon, very good (embarrassing :facepalm:) catch!
>> 
>> @dfuch, I guess `httpserver/HeadersTest.java` needs a serious overhaul against these kind of normalization edge cases. I will try tackling this tomorrow (CET). @SentryMan, let me know if you prefer picking this up yourself.
>
> The other issue you found at line 135 raises the question to _how_ strings that don't start with a letter are normalized? (A) Do we only ever put the first character as uppercase (if it's a letter)? Or (B) do we always put the first letter in a string in uppercase, wherever it appears in the string? 
> 
> Looks like the current behavior is (A) and we should stick with that, from the point of view of new tests. So, `2xyz` would be normalized as `2xyz`, but `xyz2` would be normalized as `Xyz2`. Does that make sense?

@Michael-Mc-Mahon, your expectation is correct.

In 1a849f44c01, I've addressed the bug you've spotted, and also added tests for it. Would you mind re-reviewing the changes, please?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27276#discussion_r2545259584

From dfuchs at openjdk.org  Thu Nov 20 10:14:16 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 10:14:16 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v4]
In-Reply-To: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
Message-ID: <WAI7whOtQEEoKMO8vzNn4VZlQLPtsnewhUNMiuQMRQE=.f6832263-8f0b-419f-872e-e77fc22f90f7@github.com>

> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28395/files
  - new: https://git.openjdk.org/jdk/pull/28395/files/bdc84659..371dfced

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

PR: https://git.openjdk.org/jdk/pull/28395

From jpai at openjdk.org  Thu Nov 20 10:18:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 10:18:01 GMT
Subject: RFR: 8371557:
 java/net/httpclient/http3/H3RequestRejectedTest.java:
 javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote
 endpoint (loopback) ports conflict
In-Reply-To: <bOyTNOjcEMePV95K5pS9VCEMrsUk7kGVAQZYMYAbp38=.7ac0671f-aa56-4828-8d00-446d0bf1f9c5@github.com>
References: <bOyTNOjcEMePV95K5pS9VCEMrsUk7kGVAQZYMYAbp38=.7ac0671f-aa56-4828-8d00-446d0bf1f9c5@github.com>
Message-ID: <i0ZLJaQ6DI_zwWAfyHQ5jW2HsPWz_AcSzXvK2g_O0y4=.f95e720e-94e9-49c8-8df3-10f0c882880d@github.com>

On Fri, 14 Nov 2025 17:03:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/httpclient/http3/H3RequestRejectedTest.java fails intermittently (rarely) on macOS with javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote endpoint (loopback) ports conflict.
> 
> This is a well known issue on macOS, which can be avoided by having the client bind specifically to the loopback instead of the wildcard.
> 
> A couple of methods have been added to HttpServerAdapters (newClientBuilderForH3() / createClientBuilderForH3()) to obtain a client builder pre-configured to bind to the loopback.
> 
> Most HTTP/3 test call those methods, but java/net/httpclient/http3/H3RequestRejectedTest.java doesn't, hence the intermittent failure.

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28326#pullrequestreview-3486861695

From dfuchs at openjdk.org  Thu Nov 20 10:22:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 10:22:59 GMT
Subject: Integrated: 8371557:
 java/net/httpclient/http3/H3RequestRejectedTest.java:
 javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote
 endpoint (loopback) ports conflict
In-Reply-To: <bOyTNOjcEMePV95K5pS9VCEMrsUk7kGVAQZYMYAbp38=.7ac0671f-aa56-4828-8d00-446d0bf1f9c5@github.com>
References: <bOyTNOjcEMePV95K5pS9VCEMrsUk7kGVAQZYMYAbp38=.7ac0671f-aa56-4828-8d00-446d0bf1f9c5@github.com>
Message-ID: <LmYG9ONxKL5VAdfZvcNLx1Aqb_Gufy-CEfwkF8bBlOI=.19efe915-205c-460e-9685-ebc80e03dff2@github.com>

On Fri, 14 Nov 2025 17:03:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> java/net/httpclient/http3/H3RequestRejectedTest.java fails intermittently (rarely) on macOS with javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote endpoint (loopback) ports conflict.
> 
> This is a well known issue on macOS, which can be avoided by having the client bind specifically to the loopback instead of the wildcard.
> 
> A couple of methods have been added to HttpServerAdapters (newClientBuilderForH3() / createClientBuilderForH3()) to obtain a client builder pre-configured to bind to the loopback.
> 
> Most HTTP/3 test call those methods, but java/net/httpclient/http3/H3RequestRejectedTest.java doesn't, hence the intermittent failure.

This pull request has now been integrated.

Changeset: ad38a125
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad38a1253ae3ff92f7e0cf0fbc4d4726957b1443
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8371557: java/net/httpclient/http3/H3RequestRejectedTest.java: javax.net.ssl.SSLHandshakeException: local endpoint (wildcard) and remote endpoint (loopback) ports conflict

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/28326

From vyazici at openjdk.org  Thu Nov 20 10:29:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 20 Nov 2025 10:29:32 GMT
Subject: RFR: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize [v3]
In-Reply-To: <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
Message-ID: <Vu-pOlafhX3YCGHXvAYNN-p9HcWJaHaaGa2WD0DBKbk=.ecb04bf0-ed5a-4715-bda5-f57c54fbe0d1@github.com>

On Wed, 19 Nov 2025 14:09:09 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch 2

Performance figures using 1a849f44c01:


Benchmark                                            (key)  Mode  Cnt     Score     Error   Units
HeaderNormalization.n25                     Accept-charset  avgt   15    12.384 ?   0.238   ns/op
HeaderNormalization.n25                     4ccept-charset  avgt   15    12.345 ?   0.204   ns/op
HeaderNormalization.n25                     accept-charset  avgt   15    12.749 ?   0.386   ns/op
HeaderNormalization.n25                     Accept-Charset  avgt   15    12.472 ?   0.252   ns/op
HeaderNormalization.n25                     ACCEPT-CHARSET  avgt   15    12.923 ?   0.200   ns/op
HeaderNormalization.n26                     Accept-charset  avgt   15     8.087 ?   0.067   ns/op
HeaderNormalization.n26                     4ccept-charset  avgt   15     8.085 ?   0.054   ns/op
HeaderNormalization.n26                     accept-charset  avgt   15    12.488 ?   0.224   ns/op
HeaderNormalization.n26                     Accept-Charset  avgt   15    15.818 ?   0.667   ns/op
HeaderNormalization.n26                     ACCEPT-CHARSET  avgt   15    13.693 ?   0.159   ns/op


with GC statistics:


Benchmark                                            (key)  Mode  Cnt     Score     Error   Units
HeaderNormalization.n25                     Accept-charset  avgt   15    12.384 ?   0.238   ns/op
HeaderNormalization.n25:gc.alloc.rate       Accept-charset  avgt   15  8009.345 ? 153.162  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  Accept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            Accept-charset  avgt   15   129.000            counts
HeaderNormalization.n25:gc.time             Accept-charset  avgt   15    84.000                ms
HeaderNormalization.n25                     4ccept-charset  avgt   15    12.345 ?   0.204   ns/op
HeaderNormalization.n25:gc.alloc.rate       4ccept-charset  avgt   15  8033.964 ? 130.861  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  4ccept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            4ccept-charset  avgt   15    84.000            counts
HeaderNormalization.n25:gc.time             4ccept-charset  avgt   15    61.000                ms
HeaderNormalization.n25                     accept-charset  avgt   15    12.749 ?   0.386   ns/op
HeaderNormalization.n25:gc.alloc.rate       accept-charset  avgt   15  7783.679 ? 232.103  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  accept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            accept-charset  avgt   15    84.000            counts
HeaderNormalization.n25:gc.time             accept-charset  avgt   15    61.000                ms
HeaderNormalization.n25                     Accept-Charset  avgt   15    12.472 ?   0.252   ns/op
HeaderNormalization.n25:gc.alloc.rate       Accept-Charset  avgt   15  7953.160 ? 160.314  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  Accept-Charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            Accept-Charset  avgt   15   132.000            counts
HeaderNormalization.n25:gc.time             Accept-Charset  avgt   15    84.000                ms
HeaderNormalization.n25                     ACCEPT-CHARSET  avgt   15    12.923 ?   0.200   ns/op
HeaderNormalization.n25:gc.alloc.rate       ACCEPT-CHARSET  avgt   15  7674.346 ? 117.355  MB/sec
HeaderNormalization.n25:gc.alloc.rate.norm  ACCEPT-CHARSET  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n25:gc.count            ACCEPT-CHARSET  avgt   15   151.000            counts
HeaderNormalization.n25:gc.time             ACCEPT-CHARSET  avgt   15    93.000                ms
HeaderNormalization.n26                     Accept-charset  avgt   15     8.087 ?   0.067   ns/op
HeaderNormalization.n26:gc.alloc.rate       Accept-charset  avgt   15     0.007 ?   0.001  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  Accept-charset  avgt   15    ? 10??              B/op
HeaderNormalization.n26:gc.count            Accept-charset  avgt   15       ? 0            counts
HeaderNormalization.n26                     4ccept-charset  avgt   15     8.085 ?   0.054   ns/op
HeaderNormalization.n26:gc.alloc.rate       4ccept-charset  avgt   15     0.007 ?   0.001  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  4ccept-charset  avgt   15    ? 10??              B/op
HeaderNormalization.n26:gc.count            4ccept-charset  avgt   15       ? 0            counts
HeaderNormalization.n26                     accept-charset  avgt   15    12.488 ?   0.224   ns/op
HeaderNormalization.n26:gc.alloc.rate       accept-charset  avgt   15  7942.420 ? 142.330  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  accept-charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n26:gc.count            accept-charset  avgt   15   134.000            counts
HeaderNormalization.n26:gc.time             accept-charset  avgt   15    84.000                ms
HeaderNormalization.n26                     Accept-Charset  avgt   15    15.818 ?   0.667   ns/op
HeaderNormalization.n26:gc.alloc.rate       Accept-Charset  avgt   15  6278.022 ? 272.604  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  Accept-Charset  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n26:gc.count            Accept-Charset  avgt   15   188.000            counts
HeaderNormalization.n26:gc.time             Accept-Charset  avgt   15   115.000                ms
HeaderNormalization.n26                     ACCEPT-CHARSET  avgt   15    13.693 ?   0.159   ns/op
HeaderNormalization.n26:gc.alloc.rate       ACCEPT-CHARSET  avgt   15  7242.221 ?  84.263  MB/sec
HeaderNormalization.n26:gc.alloc.rate.norm  ACCEPT-CHARSET  avgt   15   104.000 ?   0.001    B/op
HeaderNormalization.n26:gc.count            ACCEPT-CHARSET  avgt   15   211.000            counts
HeaderNormalization.n26:gc.time             ACCEPT-CHARSET  avgt   15   126.000                ms


Let me highlight certain details:

### If the input is already normalized

:green_circle: Performance has increased 34%:


Benchmark                                            (key)  Mode  Cnt     Score     Error   Units
HeaderNormalization.n25                     Accept-charset  avgt   15    12.384 ?   0.238   ns/op
HeaderNormalization.n25                     4ccept-charset  avgt   15    12.345 ?   0.204   ns/op
HeaderNormalization.n26                     Accept-charset  avgt   15     8.087 ?   0.067   ns/op
HeaderNormalization.n26                     4ccept-charset  avgt   15     8.085 ?   0.054   ns/op

100 * (1 - (avg(8.087, 8.085) / avg(12.384, 12.345)))
# ? 34


The new `normalize()` incurs no GC ? see `gc.count ... ? 0` lines.

### If the input is *not* normalized

? Performance has dropped 10%:

Associated GC costs are not impacted ? see matching `gc.alloc.rate.norm` figures between `n25` and `n26`.


Benchmark                                            (key)  Mode  Cnt     Score     Error   Units
HeaderNormalization.n25                     accept-charset  avgt   15    12.749 ?   0.386   ns/op
HeaderNormalization.n25                     Accept-Charset  avgt   15    12.472 ?   0.252   ns/op
HeaderNormalization.n25                     ACCEPT-CHARSET  avgt   15    12.923 ?   0.200   ns/op
HeaderNormalization.n26                     accept-charset  avgt   15    12.488 ?   0.224   ns/op
HeaderNormalization.n26                     Accept-Charset  avgt   15    15.818 ?   0.667   ns/op
HeaderNormalization.n26                     ACCEPT-CHARSET  avgt   15    13.693 ?   0.159   ns/op

100 * (1 - (avg(12.488, 15.818, 13.693) / avg(12.749, 12.472, 12.923)))
# ? -10.106438758389258

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3557119364

From michaelm at openjdk.org  Thu Nov 20 10:54:34 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 20 Nov 2025 10:54:34 GMT
Subject: RFR: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize [v3]
In-Reply-To: <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
Message-ID: <YIs5k4-tpzmmk_O7NvkCJQhulWD9PgsEXUv7InsI0xE=.c3a14ff6-8c4a-4112-bc91-4284a80634ba@github.com>

On Wed, 19 Nov 2025 14:09:09 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch 2

Looks fine!

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27276#pullrequestreview-3487099845

From vyazici at openjdk.org  Thu Nov 20 11:33:32 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 20 Nov 2025 11:33:32 GMT
Subject: RFR: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize [v3]
In-Reply-To: <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
Message-ID: <BceTQlEqCWuGS1M7kaN0wTLoQ6v0yRyNDLuzwfcLM4s=.d4acf958-fb25-49ce-afc2-9332bbe82db5@github.com>

On Wed, 19 Nov 2025 14:09:09 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch 2

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27276#pullrequestreview-3487309374

From dfuchs at openjdk.org  Thu Nov 20 11:53:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 11:53:12 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock
Message-ID: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>

An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.

The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.

This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.

To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

-------------

Depends on: https://git.openjdk.org/jdk/pull/28395

Commit messages:
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

Changes: https://git.openjdk.org/jdk/pull/28421/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372198
  Stats: 48 lines in 3 files changed: 23 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421

PR: https://git.openjdk.org/jdk/pull/28421

From dfuchs at openjdk.org  Thu Nov 20 12:21:42 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:21:42 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v5]
In-Reply-To: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
Message-ID: <uyBg681teJF0RVBCCoZn2xY2NB4uIjDoIpgherxgbzs=.966f2e8d-7322-4fe1-9053-e846545c879f@github.com>

> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into SelectorManagerVT-8372159
 - Copyright years
 - Review feedback on test
 - Revert changes to SelectorManager::shutdown
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28395/files
  - new: https://git.openjdk.org/jdk/pull/28395/files/371dfced..d082d909

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=03-04

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

PR: https://git.openjdk.org/jdk/pull/28395

From dfuchs at openjdk.org  Thu Nov 20 12:26:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:21 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <fbZzaZTDoy8CE5Q-391sOVBezopxpDa7ggDCKJ2R3po=.cac468b3-953b-491f-8bb5-05b3222db78b@github.com>

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28421/files
  - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=00-01

  Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod
  Patch: https://git.openjdk.org/jdk/pull/28421.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421

PR: https://git.openjdk.org/jdk/pull/28421

From dfuchs at openjdk.org  Thu Nov 20 12:26:22 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:22 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <BEkaPOGOa8LRlqic4jsZvlx97AR8RVfNhjk5_1Kvips=.741bab98-7b90-4f2c-aadc-c93d62650091@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299

From dfuchs at openjdk.org  Thu Nov 20 12:26:23 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 12:26:23 GMT
Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
References: <nOtG1ONZhnfdn-Db85SbNEjVBYgLwl-XMN5aXAunYuA=.05b437d7-0645-48fe-9ff4-87be4e518b71@github.com>
Message-ID: <S8TUGJh8rmGEbyRwrMCP7SaPKA6HJG8O_HHX17gFyDw=.2eb7031f-a01d-42d1-8efc-1b49466b48dc@github.com>

On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/28421

From jpai at openjdk.org  Thu Nov 20 13:09:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 13:09:06 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v9]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <1foddKWshBaHHnubIGGV-E4Ynw-4oeD1Ag5eBlk-1J8=.c564ae9a-08f0-4d89-9379-de42e52c9d13@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  use H3ConnectionAccess in test and remove the @modules usage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/f53bf478..b37189cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=07-08

  Stats: 82 lines in 2 files changed: 28 ins; 47 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From dfuchs at openjdk.org  Thu Nov 20 13:37:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 13:37:55 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock
Message-ID: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>

An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.

The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.

This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.

To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.

This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

-------------

Depends on: https://git.openjdk.org/jdk/pull/28395

Commit messages:
 - 8372198: Avoid closing PlainHttpConnection while holding a lock

Changes: https://git.openjdk.org/jdk/pull/28430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372198
  Stats: 48 lines in 3 files changed: 23 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Thu Nov 20 13:43:17 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 13:43:17 GMT
Subject: RFR: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize [v3]
In-Reply-To: <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
Message-ID: <04t9UVm6QiExwl7AuffMsXYaQqPMXlWsNmCnWtRCSCo=.0ea2cf54-eb55-459e-9941-1daeeea34910@github.com>

On Wed, 19 Nov 2025 14:09:09 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch 2

I did an additional round of testing and all went well. Approved!

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27276#pullrequestreview-3487925610

From jpai at openjdk.org  Thu Nov 20 14:01:32 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 14:01:32 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v10]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <7vuBvrh_T5RQyYpmYGrk-SyPtuzbuVuKWtc1UvozPaU=.d39f45b9-6861-4b2e-b307-42d9e1502ce6@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  introduce HttpClientImplAccess instead of using Http3ConnectionAccess

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/b37189cb..b702ac6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=08-09

  Stats: 96 lines in 3 files changed: 67 ins; 26 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Thu Nov 20 14:05:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 20 Nov 2025 14:05:39 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v2]
In-Reply-To: <MbeJu73ms2Ch8VhzAjyIxQ2HukJPORGB6u8lsNr8olE=.d6bc8889-6eba-4e0a-8152-2c2dd578c448@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <9eFitj4chPxvZkpK8TTqtKNsnrRjI633GSFtOo41jN0=.667d36b0-3772-489f-b57c-1837028a4bd8@github.com>
 <Cb2PngsRO2kdY_ASRv4ZackvNzIwaJGcHqmH4H7zxVA=.ceef95a4-dd0f-46e9-a8fb-0f2b0228ce92@github.com>
 <6bgwf-dekiwGBoVzArBjSXuihX1bvFbbe2RQhbTeJJI=.7e351b8a-5698-412c-a2ba-33c9eccad2cc@github.com>
 <MbeJu73ms2Ch8VhzAjyIxQ2HukJPORGB6u8lsNr8olE=.d6bc8889-6eba-4e0a-8152-2c2dd578c448@github.com>
Message-ID: <vVeu-zZZupn4RgUy7WE8801xPZtWaED5W_gkhwItc8A=.14891291-690c-4fd7-84f0-7bdb1b6dec3b@github.com>

On Wed, 19 Nov 2025 13:09:52 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Hello Volkan, I wasn't aware of this test class and it looks like it has been minimally used. The `impl()` method on that test class is a package private method which then means that I will have to include a `package` statement to this new test itself. Or change the `impl()` method to `public`. For now I decided to not fiddle with it. If you would like me to pursue it further in this PR, let me know and I can do that.
>
> The idea is to use the `access` library to inject classes in (internal) packages when you need access to package protected APIs. That would not work for anything private - unless the injected class uses Lookup.privateLookupIn() to access the target class private APIs. The advantage is that it avoids to redefine the `@modules` - you don't need the additional `+open` when the accessor class (a public class) is already injected in the package

I have updated the PR to apply this suggestion of using a `HttpClientImplAccess` to peek into the internal field. This does avoid all the `@modules` in the test definition. The test continues to pass with this change. I've triggered a CI run with these changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2546184156

From duke at openjdk.org  Thu Nov 20 14:26:28 2025
From: duke at openjdk.org (duke)
Date: Thu, 20 Nov 2025 14:26:28 GMT
Subject: RFR: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize [v3]
In-Reply-To: <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
 <xIt-E4mrywzp6mCLPYN9Au8i5XE7Qc8iYSVaDMcq7K8=.9d5dbd9f-b3b0-4803-ad63-733435d3615d@github.com>
Message-ID: <JtVCX7BrNbe_dd4j8ePQ_lL4ZcsCBDR3xHOVyYAqrqQ=.3aed830d-077d-4c1a-be29-5a2adf91a100@github.com>

On Wed, 19 Nov 2025 14:09:09 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   patch 2

@SentryMan 
Your change (at version 1a849f44c01fc2a7fbdd08826e4f843ec91b6d99) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3558323388

From dfuchs at openjdk.org  Thu Nov 20 14:44:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 20 Nov 2025 14:44:03 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v10]
In-Reply-To: <7vuBvrh_T5RQyYpmYGrk-SyPtuzbuVuKWtc1UvozPaU=.d39f45b9-6861-4b2e-b307-42d9e1502ce6@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <7vuBvrh_T5RQyYpmYGrk-SyPtuzbuVuKWtc1UvozPaU=.d39f45b9-6861-4b2e-b307-42d9e1502ce6@github.com>
Message-ID: <5YbZqTnSEoBEoaVVbKGWCyV-dsenJRlZrBWKZu4orX0=.fca7565c-b10e-402a-8be3-a19590c87ac1@github.com>

On Thu, 20 Nov 2025 14:01:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   introduce HttpClientImplAccess instead of using Http3ConnectionAccess

src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2116:

> 2114:                 // that way when Http2Connection.isOpen() returns false in that situation, then this
> 2115:                 // getTerminationCause() will return a termination cause.
> 2116:                 terminate(Http2TerminationCause.forException(new IOException("channel is not open")));

Shouldn't we use `new ClosedChannelException()` here instead of `new IOException("channel is not open")`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2546322746

From duke at openjdk.org  Thu Nov 20 15:58:17 2025
From: duke at openjdk.org (Josiah Noel)
Date: Thu, 20 Nov 2025 15:58:17 GMT
Subject: Integrated: 8347167: Reduce allocation in
 com.sun.net.httpserver.Headers::normalize
In-Reply-To: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
References: <yPSllwQVd0Vw3VYWabkIaA-nNM1ThPFqa4rvmxOLnzw=.bb1436f8-3206-4c0e-9b7c-dc71a62984e1@github.com>
Message-ID: <u52vwLc6jbSjal2fZYzSVaH5WOqnLSUsVaLkYfpW1tI=.01e72a9b-598a-4a10-af06-64025351e65b@github.com>

On Mon, 15 Sep 2025 02:50:27 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized.

This pull request has now been integrated.

Changeset: ea19ad2a
Author:    Josiah Noel <32279667+SentryMan at users.noreply.github.com>
Committer: Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea19ad2ac8a1fa9d4124be9a8e05cf4c6f6231bd
Stats:     268 lines in 3 files changed: 248 ins; 0 del; 20 mod

8347167: Reduce allocation in com.sun.net.httpserver.Headers::normalize

Reviewed-by: vyazici, dfuchs, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/27276

From jpai at openjdk.org  Fri Nov 21 01:17:40 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 01:17:40 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v10]
In-Reply-To: <5YbZqTnSEoBEoaVVbKGWCyV-dsenJRlZrBWKZu4orX0=.fca7565c-b10e-402a-8be3-a19590c87ac1@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <7vuBvrh_T5RQyYpmYGrk-SyPtuzbuVuKWtc1UvozPaU=.d39f45b9-6861-4b2e-b307-42d9e1502ce6@github.com>
 <5YbZqTnSEoBEoaVVbKGWCyV-dsenJRlZrBWKZu4orX0=.fca7565c-b10e-402a-8be3-a19590c87ac1@github.com>
Message-ID: <LdgW5n2spg1DYsaUwQfLRKRUylbGAoeRgW2pB_GYP2A=.2b56ac10-714c-43a9-a522-aa2de73e0486@github.com>

On Thu, 20 Nov 2025 14:40:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   introduce HttpClientImplAccess instead of using Http3ConnectionAccess
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2Connection.java line 2116:
> 
>> 2114:                 // that way when Http2Connection.isOpen() returns false in that situation, then this
>> 2115:                 // getTerminationCause() will return a termination cause.
>> 2116:                 terminate(Http2TerminationCause.forException(new IOException("channel is not open")));
> 
> Shouldn't we use `new ClosedChannelException()` here instead of `new IOException("channel is not open")`

Thank you for catching that. I had forgotten to update it after our discussion few days back. I've done it now and the tier testing continues to pass with this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2548209526

From jpai at openjdk.org  Fri Nov 21 01:17:37 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 21 Nov 2025 01:17:37 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  use ClosedChannelException instead of IOException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/b702ac6e..79ff938b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=09-10

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From djelinski at openjdk.org  Fri Nov 21 09:49:52 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 09:49:52 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v4]
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <dq3YHt-vWLwzNiSUGi0MpFQrH2HDDStoA64U4OLS1tM=.c5f50535-a3fc-411c-a63b-fc0b63d377cc@github.com>

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with four additional commits since the last revision:

 - Add test coverage for Reno
 - Refactor target calculations
 - Refactor QuicBaseCC constructor
 - remove useless protected keyword

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28195/files
  - new: https://git.openjdk.org/jdk/pull/28195/files/195b0f89..32160ef9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=02-03

  Stats: 78 lines in 6 files changed: 45 ins; 7 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28195/head:pull/28195

PR: https://git.openjdk.org/jdk/pull/28195

From djelinski at openjdk.org  Fri Nov 21 10:10:16 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 10:10:16 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v5]
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <fDAPLX2f6ZXsOS9XfDkl_M9F8kyImiMDzvnyB-81kyo=.1d73d709-545c-468c-8c64-bff09e41c67c@github.com>

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Add more assertions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28195/files
  - new: https://git.openjdk.org/jdk/pull/28195/files/32160ef9..2b47732e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=03-04

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28195/head:pull/28195

PR: https://git.openjdk.org/jdk/pull/28195

From duke at openjdk.org  Fri Nov 21 10:16:11 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Fri, 21 Nov 2025 10:16:11 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v5]
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <PRdhqaFxZXDXxpsPEbKlgfeyLX7UaRkbD_y_M8_AARs=.8cbf5568-bc68-45cb-815d-e7b097c85ff3@github.com>

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Oumaiyma Intissar has updated the pull request incrementally with one additional commit since the last revision:

  8367049: URL.openConnection throws StringIndexOutOfBoundsException in avm mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27896/files
  - new: https://git.openjdk.org/jdk/pull/27896/files/409b886a..a62187b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From duke at openjdk.org  Fri Nov 21 10:16:12 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Fri, 21 Nov 2025 10:16:12 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v4]
In-Reply-To: <GyFbYh9du-6y-bw4lxsRDz_BiV-7Vprm6HkrTGq1uEw=.626c978a-330e-46c9-9bf9-0daf88822c12@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <ZKXGY5Wz3y0NQr7CGAK8IKkyYF5k8jKwcWJqM_pb9X0=.5265046a-73b4-4026-b362-64c41ffa509d@github.com>
 <GyFbYh9du-6y-bw4lxsRDz_BiV-7Vprm6HkrTGq1uEw=.626c978a-330e-46c9-9bf9-0daf88822c12@github.com>
Message-ID: <Oi-qfq_8b57iLuYzl7m3eKnlHrrc-cKe2oZhOR4F6DY=.a3c0a7fe-83c7-44d0-b816-e7a1350bd508@github.com>

On Tue, 18 Nov 2025 14:51:47 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> LGTM - please run tier2 before integrating.

thanks! tier1, tier2 and tier3 are tested and passing well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27896#issuecomment-3562328918

From duke at openjdk.org  Fri Nov 21 10:20:38 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Fri, 21 Nov 2025 10:20:38 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v6]
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <dRH4WtdiTXH7GbbwfbsTDCdujlqAZZ-A6vt0674EItA=.88d26cbc-0cfc-41e8-ab7c-b30760c24e94@github.com>

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Oumaiyma Intissar has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8367049: URLPermission.<init> throws StringIndexOutOfBoundsException in avm mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27896/files
  - new: https://git.openjdk.org/jdk/pull/27896/files/a62187b4..d154b1db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=04-05

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From djelinski at openjdk.org  Fri Nov 21 10:21:04 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 10:21:04 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
Message-ID: <hFRbzKfyDK6a4Y2cdDDX8B0ekfPqQkmpfAFvzkh1now=.2baaf078-2d2a-4792-b43b-f2cb38f38320@github.com>

On Fri, 14 Nov 2025 12:18:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Update test comments
>>  - Convert CubicTest to JUnit
>>  - Merge declaration and assignment
>>  - More aggressive target growth
>>  - Merge remote-tracking branch 'origin/master' into quic-cubic
>>  - Make classes final
>>  - Rename system property to internal
>>  - Add a system property to select congestion controller
>>  - Implement fast convergence
>>  - Add comments
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/1f1f7bb4...195b0f89
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicBaseCongestionController.java line 69:
> 
>> 67:     protected long maxBytesInFlight;
>> 68:     protected Deadline congestionRecoveryStartTime;
>> 69:     protected long ssThresh = Long.MAX_VALUE;
> 
> Can we remove the `protected` keyword on the mutable fields? All the subclasses are in the same package.

Done.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicBaseCongestionController.java line 84:
> 
>> 82:         this.timeSource = source;
>> 83:         this.pacer = new QuicPacer(rttEstimator, this);
>> 84:     }
> 
> Suggestion:
> 
>     protected QuicBaseCongestionController(String dbgTag, QuicRttEstimator rttEstimator) {
>         this(dbgTag, TimeSource.source(), rttEstimator);
>     }
> 
>     // Allows to pass a custom TimeLine when testing
>     QuicBaseCongestionController(String dbgTag, TimeLine source, QuicRttEstimator rttEstimator) {
>         this.dbgTag = dbgTag;
>         this.timeSource = source;
>         this.pacer = new QuicPacer(rttEstimator, this);
>     }

Done.

> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 124:
> 
>> 122:             // not sure if dblTarget can overflow a long, but 1.5 congestionWindow can not.
>> 123:             if (dblTargetBytes > 1.5 * congestionWindow) {
>> 124:                 targetBytes = (long) (1.5 * congestionWindow);
> 
> Suggestion:
> 
>             // targetLimit is 1.5 * congestionWindow
>             long targetLimit = congestionWindow + (congestionWindow >> 1)
>             if (dblTargetBytes > targetLimit) {
>                 targetBytes = targetLimit;

Refactored the code, I think it's easier to follow now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2549245195
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2549245648
PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2549248271

From djelinski at openjdk.org  Fri Nov 21 10:21:00 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 10:21:00 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v5]
In-Reply-To: <fDAPLX2f6ZXsOS9XfDkl_M9F8kyImiMDzvnyB-81kyo=.1d73d709-545c-468c-8c64-bff09e41c67c@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <fDAPLX2f6ZXsOS9XfDkl_M9F8kyImiMDzvnyB-81kyo=.1d73d709-545c-468c-8c64-bff09e41c67c@github.com>
Message-ID: <EIJGPFSJotfvLakIHaAPLqXGbcKDeRiiiXLmAftyxSE=.deadf929-3f33-474a-8f3a-4f22c7d3d8a5@github.com>

On Fri, 21 Nov 2025 10:10:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more assertions

Thanks @dfuch for the review.

We didn't have any Reno-specific tests. I modified a few of the existing tests to also run with Reno now.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28195#pullrequestreview-3491960507

From djelinski at openjdk.org  Fri Nov 21 10:21:07 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 10:21:07 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <0vLD4TJVLBgs0Kq66JBsL1YO5dg2QeKTOWDtA1yYE-c=.1c7036f3-d37a-44c7-8201-b1cdab1abc12@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <0vLD4TJVLBgs0Kq66JBsL1YO5dg2QeKTOWDtA1yYE-c=.1c7036f3-d37a-44c7-8201-b1cdab1abc12@github.com>
Message-ID: <_yirtDN8g9UrSLG9jW7gCsgbG2J0xbVBa-s7SLWc6iQ=.f369e5bb-14d1-4601-8559-bd6c96f60bcf@github.com>

On Mon, 17 Nov 2025 12:37:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/quic/QuicCubicCongestionController.java line 114:
>> 
>>> 112:         if (!isAppLimited) {
>>> 113:             if (wEstBytes < cwndPriorBytes) {
>>> 114:                 wEstBytes += Math.max((long) (ALPHA * maxDatagramSize * packetBytes / congestionWindow), 1);
>> 
>> should we assert that congestionWindow is > 2 ?
>
> The congestion window is in bytes, and it's never reduced below 2*maxDatagramSize, which is never less than 2400. Not sure if we should add that particular assertion, but it would probably make sense to assert that packetAcked does not decrease the congestion window. I'll see what I can do.

I added the assertion in the base class

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2549159411

From djelinski at openjdk.org  Fri Nov 21 10:21:09 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 10:21:09 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <3yNjwr_b3mSZbMjeZ96UPD5uljqf0ovW97qgpCRiokI=.3f5958d1-0d09-489c-86a5-11196f81498d@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <r3ieSzkVzYHU5LXdUlIX0pdkhBPVnK-PZxKN64esdWk=.bc266a4c-2aa0-44fb-8fa1-c1bae284c700@github.com>
 <HokEl9CQdNIi_dteVhqCairjr_MbN5GjOagQ9GFVcu8=.59858dd9-4c59-4d6a-bec1-9e45101beba2@github.com>
 <3yNjwr_b3mSZbMjeZ96UPD5uljqf0ovW97qgpCRiokI=.3f5958d1-0d09-489c-86a5-11196f81498d@github.com>
Message-ID: <xTnjnfrruFykeh1N1vu2wpKarz2GymEoyxbkw0jS5Ew=.6783654c-25e8-4b6b-9fd5-c416681443fb@github.com>

On Mon, 17 Nov 2025 15:24:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> It cannot overflow when used correctly (i.e. when packetBytes < congestionWindow, and congestionWindow < 2 * MAX_BYTES_IN_FLIGHT).
>
> if congestionWindow >= minimumWindow is an invariant, maybe we should assert it whenever we change congestionWindow.

Added the assertions in the base class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2549222644

From djelinski at openjdk.org  Fri Nov 21 10:21:11 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 10:21:11 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <mM6bzC4BPBu-sNNCpVAt-QqdrgzYTCIv0lE4o25J_dE=.ca6959dc-e072-4f0e-a4de-584c469cbc65@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <sXuj3QyJBLMQvck8ixdsJypetftId5jQC4YEXckTBqM=.871b7a6c-55a9-497a-b15f-4feff91f366e@github.com>
 <mM6bzC4BPBu-sNNCpVAt-QqdrgzYTCIv0lE4o25J_dE=.ca6959dc-e072-4f0e-a4de-584c469cbc65@github.com>
Message-ID: <blczvQe5ufmXRjQzrup24YizBPUNzyNylaklyl6bKok=.4e127ac1-828b-45a7-9b3b-c63ff81d82f0@github.com>

On Mon, 17 Nov 2025 15:16:32 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Well that's an interesting question. The RFC does not suggest clamping wMaxBytes in any way, so we sometimes do end up with wMaxBytes < congestionWindow, and kNanos < 0, even in the `testReduction` test. That seems to be in line with the RFC.
>> 
>> A negative `k` value is pretty well tolerated by the algorithm. It just means that we will start increasing the window slightly faster than we would otherwise.
>
> OK then. Could be worth adding a comment that kNanos can be negative and that it is OK.

Comment added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2549250174

From michaelm at openjdk.org  Fri Nov 21 12:19:43 2025
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 21 Nov 2025 12:19:43 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v6]
In-Reply-To: <dRH4WtdiTXH7GbbwfbsTDCdujlqAZZ-A6vt0674EItA=.88d26cbc-0cfc-41e8-ab7c-b30760c24e94@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <dRH4WtdiTXH7GbbwfbsTDCdujlqAZZ-A6vt0674EItA=.88d26cbc-0cfc-41e8-ab7c-b30760c24e94@github.com>
Message-ID: <624VsybxaZgWLCrRmFTIW1fvRDeQht75XteTi9Oa4Ak=.1e23d699-3ffc-4c68-99b2-c91cdb75b498@github.com>

On Fri, 21 Nov 2025 10:20:38 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8367049: URLPermission.<init> throws StringIndexOutOfBoundsException in avm mode

LGTM

-------------

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27896#pullrequestreview-3492513961

From duke at openjdk.org  Fri Nov 21 13:05:03 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Fri, 21 Nov 2025 13:05:03 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v7]
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <ueCmYBS0Oi89bSk9enTJHTZi8hvmLfoCR8E6SJEx7I8=.65b6d435-2b6a-4bf1-8ab4-6bd9e6c45582@github.com>

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

Oumaiyma Intissar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8367049
 - 8367049: URLPermission.<init> throws StringIndexOutOfBoundsException in avm mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27896/files
  - new: https://git.openjdk.org/jdk/pull/27896/files/d154b1db..543f2379

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27896&range=05-06

  Stats: 335412 lines in 3196 files changed: 215606 ins; 75843 del; 43963 mod
  Patch: https://git.openjdk.org/jdk/pull/27896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27896/head:pull/27896

PR: https://git.openjdk.org/jdk/pull/27896

From dfuchs at openjdk.org  Fri Nov 21 13:05:03 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Nov 2025 13:05:03 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v7]
In-Reply-To: <ueCmYBS0Oi89bSk9enTJHTZi8hvmLfoCR8E6SJEx7I8=.65b6d435-2b6a-4bf1-8ab4-6bd9e6c45582@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <ueCmYBS0Oi89bSk9enTJHTZi8hvmLfoCR8E6SJEx7I8=.65b6d435-2b6a-4bf1-8ab4-6bd9e6c45582@github.com>
Message-ID: <3kUxaOkskEkBljnuMnig7mWNODN92dEvLzmqYWsXfJA=.ef4d2467-4e15-4efd-8d99-d1f5ab3e9b9e@github.com>

On Fri, 21 Nov 2025 13:01:07 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8367049
>  - 8367049: URLPermission.<init> throws StringIndexOutOfBoundsException in avm mode

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27896#pullrequestreview-3492665933

From duke at openjdk.org  Fri Nov 21 15:30:16 2025
From: duke at openjdk.org (duke)
Date: Fri, 21 Nov 2025 15:30:16 GMT
Subject: RFR: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode [v7]
In-Reply-To: <ueCmYBS0Oi89bSk9enTJHTZi8hvmLfoCR8E6SJEx7I8=.65b6d435-2b6a-4bf1-8ab4-6bd9e6c45582@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
 <ueCmYBS0Oi89bSk9enTJHTZi8hvmLfoCR8E6SJEx7I8=.65b6d435-2b6a-4bf1-8ab4-6bd9e6c45582@github.com>
Message-ID: <kSdflrztxJMb6MBcOmm4omVSCVMXDW_CQMW95BkvUtE=.8b1a928c-771a-45a4-9869-1690f08ebcbe@github.com>

On Fri, 21 Nov 2025 13:05:03 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

>> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
>> 
>> **Problem**
>> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
>> 
>> **Fix**
>> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
>> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
>> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
>> 
>> **Compatibility**
>> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
>> 
>> **Testing**
>> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.
>
> Oumaiyma Intissar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8367049
>  - 8367049: URLPermission.<init> throws StringIndexOutOfBoundsException in avm mode

@OumaIntissar 
Your change (at version 543f2379bf59b6533c6379c8c1e3c5e4cdb1c933) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27896#issuecomment-3563499433

From duke at openjdk.org  Fri Nov 21 15:46:12 2025
From: duke at openjdk.org (Oumaiyma Intissar)
Date: Fri, 21 Nov 2025 15:46:12 GMT
Subject: Integrated: 8367049: URLPermission.<init> throws
 StringIndexOutOfBoundsException in avm mode
In-Reply-To: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
References: <zAuUBZH4MICE_EtUOSeajA0sE1l7szUQaKl-IpCkgHw=.051b7c3c-010c-44ef-9972-a22a7f8763e4@github.com>
Message-ID: <k4V_rnZUGmLsVnHjXTjP4qK2GBzyz7Xvy5PdKOIDWeA=.20963c40-2e1b-4052-90f0-7c66ce0ab1d3@github.com>

On Mon, 20 Oct 2025 12:12:56 GMT, Oumaiyma Intissar <duke at openjdk.org> wrote:

> Constructing URLPermission with an empty/missing host in the authority (e.g., `"http:///path"`) could throw `StringIndexOutOfBoundsException`.
> 
> **Problem**
> Empty or malformed authorities reach HostPortrange, which does `charAt(0)` without checking, causing `StringIndexOutOfBoundsException`.
> 
> **Fix**
> - `URLPermission.Authority`: after stripping userinfo, fail fast if host part is empty.
> - `HostPortrange`: add guards for null/empty input and leading ':' (port without host).
> - No `HttpURLConnection` changes needed in JDK 26 (the `SecurityManager` permission path is gone).
> 
> **Compatibility**
> Only affects malformed inputs: previously `StringIndexOutOfBoundsException`, now `IllegalArgumentException`. Valid inputs unaffected.
> 
> **Testing**
> New jtreg test: `test/jdk/java/net/URLPermission/EmptyAuthorityTest.java` verifies `IllegalArgumentException` for malformed authorities and success for valid ones.

This pull request has now been integrated.

Changeset: 5f806e7f
Author:    Oumaiyma Intissar <49239111+OumaIntissar at users.noreply.github.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f806e7f8b66c14954a07005be3bceb2f812fbff
Stats:     76 lines in 3 files changed: 76 ins; 0 del; 0 mod

8367049: URLPermission.<init> throws StringIndexOutOfBoundsException in avm mode

Reviewed-by: michaelm, dfuchs, coffeys

-------------

PR: https://git.openjdk.org/jdk/pull/27896

From dfuchs at openjdk.org  Fri Nov 21 16:02:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Nov 2025 16:02:48 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v5]
In-Reply-To: <fDAPLX2f6ZXsOS9XfDkl_M9F8kyImiMDzvnyB-81kyo=.1d73d709-545c-468c-8c64-bff09e41c67c@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <fDAPLX2f6ZXsOS9XfDkl_M9F8kyImiMDzvnyB-81kyo=.1d73d709-545c-468c-8c64-bff09e41c67c@github.com>
Message-ID: <MaXwZctgOtHekSBjrTtxPxuAtjKbuNHYWopLtObQ6oo=.66748254-e8d3-4ec5-bb21-50df49f26a49@github.com>

On Fri, 21 Nov 2025 10:10:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more assertions

New changes look good to me. Please make sure tests remain stable before integrating.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28195#pullrequestreview-3493382078

From dfuchs at openjdk.org  Fri Nov 21 16:02:49 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 21 Nov 2025 16:02:49 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <blczvQe5ufmXRjQzrup24YizBPUNzyNylaklyl6bKok=.4e127ac1-828b-45a7-9b3b-c63ff81d82f0@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <sXuj3QyJBLMQvck8ixdsJypetftId5jQC4YEXckTBqM=.871b7a6c-55a9-497a-b15f-4feff91f366e@github.com>
 <mM6bzC4BPBu-sNNCpVAt-QqdrgzYTCIv0lE4o25J_dE=.ca6959dc-e072-4f0e-a4de-584c469cbc65@github.com>
 <blczvQe5ufmXRjQzrup24YizBPUNzyNylaklyl6bKok=.4e127ac1-828b-45a7-9b3b-c63ff81d82f0@github.com>
Message-ID: <7rZsfSm2KOWlBgjEsvIjFVQ3Xh3IroKH6d_cbnPpRmc=.757c3e36-bd0d-4188-9c5c-0f681062a264@github.com>

On Fri, 21 Nov 2025 10:15:58 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> OK then. Could be worth adding a comment that kNanos can be negative and that it is OK.
>
> Comment added.

Not seeing the comment - maybe you haven't pushed it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2550238177

From mdonovan at openjdk.org  Fri Nov 21 19:51:57 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 19:51:57 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
Message-ID: <E8Cv9YJqeMcmIHDtVKWojBGlRp1Jxb-iKxlYOmMasYg=.148a6982-c399-468e-9795-072d01b1c983@github.com>

On Thu, 13 Nov 2025 13:49:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed line wrapping
>
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 36:
> 
>> 34:  * @library /test/lib
>> 35:  * @modules java.base/sun.security.x509 java.base/sun.security.util
>> 36:  * @run main/othervm CriticalSubjectAltName TLSv1.2 MD5withRSA
> 
> as far as I could tell, this test doesn't verify any functionality that would require a specific key type, it's simply using MD5 because that was the popular choice in 2008. Do we need to keep using MD5, or can we make it use whatever key type is the default?

It was suggested to keep test cases for TLS 1.2/MD5 as well as updating for TLS 1.3. If the TLS 1.2/MD5 isn't adding anything here I can remove it.

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java line 1:
> 
>> 1: /*
> 
> This might be preexisting, but this file is identical to `test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java` now. Can we remove one?

I compared the two files from before I updated IPIdentities and they are identical. I removed IPIdentities.java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550794961
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550797069

From mdonovan at openjdk.org  Fri Nov 21 19:51:58 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 19:51:58 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v5]
In-Reply-To: <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
 <aA5qTXgzS9THMJ4CixOErCZQgoNinlpVG5smUJR2r8w=.7cfce56c-c519-4145-b95b-d9c25e283019@github.com>
 <k0HaJQgs8MfPE7lwS6NdzMXMlHgFACLozmxm37bcQ2I=.96db4b27-1332-49fb-91fc-8af7a5dbb4dd@github.com>
Message-ID: <MyUqaUSXqScHBkvmqAnNyrqyodsf7vHBrFVCteXmgIo=.4a124dc2-e169-43a6-8fb1-4640d1be1b1e@github.com>

On Fri, 14 Nov 2025 10:04:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 104:
>> 
>>> 102:                         CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)
>>> 103:                 .addBasicConstraintsExt(false, false, -1)
>>> 104:                 .addExtension(CertificateBuilder.createIPSubjectAltNameExt(true, "127.0.0.1"))
>> 
>> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities
>
> If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

> I assume you verified that the DNSIdentities customization overwrites the SAN configured here, but I'd feel more confident if this line were moved to customizeServerCert in IPIdentities

Yes, they are overwritten, extensions are stored as a Map between extention id and the extension.

> If there is an alternative SAN for IPv4 loopback address there should be one for the IPv6 loopback too.

I added the IPV6 loopback.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2550800219

From mdonovan at openjdk.org  Fri Nov 21 20:14:53 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 21 Nov 2025 20:14:53 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v6]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <POyghquA73E5_k3iKqZEGHCuu-se97Wm1kqlvTUuqbY=.77c9714a-8c4a-4e32-8bcf-71706f921919@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Updated SAN methods in CertificateBuilder to take multiple names
 - Merge branch 'master' into update-md5-certs
 - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
 - removed unused keystore files, fixed certificate chain
 - Merge branch 'master' into update-md5-certs
 - changed line wrapping
 - removed unnecessary comment and made getSSLContext(...) private
 - changed tests to use SecurityUtils.removeDisabled*Algs methods
 - fixed indents and copyright year
 - Merge branch 'master' into update-md5-certs
 - ... and 1 more: https://git.openjdk.org/jdk/compare/c70734d2...6579bc79

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/1aaf4247..6579bc79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=04-05

  Stats: 300342 lines in 2569 files changed: 194979 ins; 65676 del; 39687 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From djelinski at openjdk.org  Fri Nov 21 21:14:18 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 21:14:18 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v6]
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <orvmuzXwlc90WDD6dL87STOeljMnNHGnAX1Ji2V7my8=.b202d5b4-22d6-4e7e-9ce8-60f7dfaa7a47@github.com>

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Add comment for negative K

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28195/files
  - new: https://git.openjdk.org/jdk/pull/28195/files/2b47732e..60680962

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28195&range=04-05

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28195/head:pull/28195

PR: https://git.openjdk.org/jdk/pull/28195

From djelinski at openjdk.org  Fri Nov 21 21:14:20 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 21:14:20 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v3]
In-Reply-To: <7rZsfSm2KOWlBgjEsvIjFVQ3Xh3IroKH6d_cbnPpRmc=.757c3e36-bd0d-4188-9c5c-0f681062a264@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <X9OqSo8B1c9H-0BnGAIx2OoWdtarql6gbBFFH2U7uHw=.e0f82db5-8ec5-4a10-8adc-eb830df85cdd@github.com>
 <NVTqsyn0l8vLjOZgnonE1-QjQfCl-3Ik5Reh5Z_sah8=.ed45bb70-131b-4f9c-91a6-8fe9914bf34b@github.com>
 <sXuj3QyJBLMQvck8ixdsJypetftId5jQC4YEXckTBqM=.871b7a6c-55a9-497a-b15f-4feff91f366e@github.com>
 <mM6bzC4BPBu-sNNCpVAt-QqdrgzYTCIv0lE4o25J_dE=.ca6959dc-e072-4f0e-a4de-584c469cbc65@github.com>
 <blczvQe5ufmXRjQzrup24YizBPUNzyNylaklyl6bKok=.4e127ac1-828b-45a7-9b3b-c63ff81d82f0@github.com>
 <7rZsfSm2KOWlBgjEsvIjFVQ3Xh3IroKH6d_cbnPpRmc=.757c3e36-bd0d-4188-9c5c-0f681062a264@github.com>
Message-ID: <nQeanH02X1RwAYK5phCsWbo08bZI1gsWy5ggXNNDRuc=.7bb68d43-2ff8-4dfc-aabf-42dfed576677@github.com>

On Fri, 21 Nov 2025 15:59:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Comment added.
>
> Not seeing the comment - maybe you haven't pushed it?

yeah, that was it. Pushed now - thanks for checking!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28195#discussion_r2550965329

From djelinski at openjdk.org  Fri Nov 21 21:54:17 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 21 Nov 2025 21:54:17 GMT
Subject: RFR: 8372344: QUIC transfer may deadlock if pacing rate is too high
Message-ID: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>

Modify the PacketTransmissionTask to update the current deadline (`now`) between loop iterations.

This fixes the deadlock issue which happened when the next deadline was equal to the current one, but no progress could be made because the pacer quota only increases as time passes.

No new test; the issue was extremely rare. Existing tests continue to pass.

-------------

Commit messages:
 - Fix deadlock in packet transmission task

Changes: https://git.openjdk.org/jdk/pull/28462/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28462&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372344
  Stats: 10 lines in 1 file changed: 2 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28462.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28462/head:pull/28462

PR: https://git.openjdk.org/jdk/pull/28462

From jbhateja at openjdk.org  Sun Nov 23 11:50:08 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 23 Nov 2025 11:50:08 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v2]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <LReM4-4El55LtXux3Oz2JEVfoIw3p_aGX7fOJrPNKRs=.a64a0d0b-ad33-4fd5-95d3-74f318d61cc3@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added HalffloatVector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Cleaning up interface as per review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28002/files
  - new: https://git.openjdk.org/jdk/pull/28002/files/c60d533c..ea3ef19b

Webrevs:
 - full: Webrev is not available because diff is too large
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=00-01

  Stats: 162997 lines in 187 files changed: 75266 ins; 74548 del; 13183 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From djelinski at openjdk.org  Mon Nov 24 10:09:25 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 10:09:25 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
Message-ID: <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>

On Fri, 21 Nov 2025 01:17:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use ClosedChannelException instead of IOException

Marked as reviewed by djelinski (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 268:

> 266:     private static final class InternalError extends Http2TerminationCause {
> 267:         private InternalError(final Throwable cause) {
> 268:             super(ErrorFrame.INTERNAL_ERROR, new Exception(cause));

why do we need to wrap the throwable here?

test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 128:

> 126:             final Set<?> openedConnections = HttpClientImplAccess.getOpenedConnections(client);
> 127:             assumeTrue(openedConnections != null,
> 128:                     "skipping test against HttpClient of type " + client.getClass().getName());

Please remove. The HttpClient will always be of the expected type, and keeping this code around will only make it harder to spot when the assumption no longer holds.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28233#pullrequestreview-3499234926
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555375656
PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555528331

From jpai at openjdk.org  Mon Nov 24 10:17:17 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 10:17:17 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
 <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
Message-ID: <Mbso7De6ZMYmDANWsFMSxFpQOveHpgw-De-qBFNveQY=.d342b437-2673-4f94-b63b-dc62aec2a63a@github.com>

On Mon, 24 Nov 2025 09:59:12 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ClosedChannelException instead of IOException
>
> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 128:
> 
>> 126:             final Set<?> openedConnections = HttpClientImplAccess.getOpenedConnections(client);
>> 127:             assumeTrue(openedConnections != null,
>> 128:                     "skipping test against HttpClient of type " + client.getClass().getName());
> 
> Please remove. The HttpClient will always be of the expected type, and keeping this code around will only make it harder to spot when the assumption no longer holds.

Hello Daniel, my understanding is that the `HttpClient` default implementation in the JDK will be `jdk.internal.net.http.HttpClientImpl`, but if these tests are run against any other implementation of the `HttpClient` then this test is going to fail to find that internal state. If that isn't a practical concern, then I will go ahead and remove this skipping of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555591315

From jpai at openjdk.org  Mon Nov 24 10:25:14 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 10:25:14 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v12]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <Vk8jPIqCJ_B_AMWZkYxowN7t5khNMfdCQjY_IpdTlzA=.5bb45a81-98b5-47f2-a029-9871df2feaeb@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - merge latest from master branch
 - Daniel's review - remove unnecessary wrapping of exception
 - use ClosedChannelException instead of IOException
 - introduce HttpClientImplAccess instead of using Http3ConnectionAccess
 - use H3ConnectionAccess in test and remove the @modules usage
 - Remove import
 - use Utils.toIOException()
 - rename method
 - remove unneeded method
 - logging and javadoc comment fixes
 - ... and 16 more: https://git.openjdk.org/jdk/compare/48d16249...b7389dde

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/79ff938b..b7389dde

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=10-11

  Stats: 38731 lines in 529 files changed: 28109 ins; 7580 del; 3042 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Mon Nov 24 10:25:16 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 10:25:16 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
 <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
Message-ID: <8fEeWzy6eFREf_9w95BCagx2ovJzbIxsUUKIVNShB8E=.18bdad22-a48f-48db-93a3-4e05cd21d5a9@github.com>

On Mon, 24 Nov 2025 09:25:22 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use ClosedChannelException instead of IOException
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 268:
> 
>> 266:     private static final class InternalError extends Http2TerminationCause {
>> 267:         private InternalError(final Throwable cause) {
>> 268:             super(ErrorFrame.INTERNAL_ERROR, new Exception(cause));
> 
> why do we need to wrap the throwable here?

I don't remember why I did that this way, but it looks like a leftover from my experiments. I've updated the PR to remove this wrapping. Thank you for catching this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555626256

From djelinski at openjdk.org  Mon Nov 24 10:53:56 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 10:53:56 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <Mbso7De6ZMYmDANWsFMSxFpQOveHpgw-De-qBFNveQY=.d342b437-2673-4f94-b63b-dc62aec2a63a@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
 <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
 <Mbso7De6ZMYmDANWsFMSxFpQOveHpgw-De-qBFNveQY=.d342b437-2673-4f94-b63b-dc62aec2a63a@github.com>
Message-ID: <C-xWYuY73i_gp8ZDL-MKDxgAhUGiacitCvLf_EtlGgE=.bcb4ceae-068e-47fa-8a23-ec1705ac53a9@github.com>

On Mon, 24 Nov 2025 10:14:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 128:
>> 
>>> 126:             final Set<?> openedConnections = HttpClientImplAccess.getOpenedConnections(client);
>>> 127:             assumeTrue(openedConnections != null,
>>> 128:                     "skipping test against HttpClient of type " + client.getClass().getName());
>> 
>> Please remove. The HttpClient will always be of the expected type, and keeping this code around will only make it harder to spot when the assumption no longer holds.
>
> Hello Daniel, my understanding is that the `HttpClient` default implementation in the JDK will be `jdk.internal.net.http.HttpClientImpl`, but if these tests are run against any other implementation of the `HttpClient` then this test is going to fail to find that internal state. If that isn't a practical concern, then I will go ahead and remove this skipping of the test.

We don't have similar checks in any of the other whitebox tests, so I think we can safely assume that HttpClientImpl is the only implementation we test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555747877

From dfuchs at openjdk.org  Mon Nov 24 11:06:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 11:06:00 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v6]
In-Reply-To: <orvmuzXwlc90WDD6dL87STOeljMnNHGnAX1Ji2V7my8=.b202d5b4-22d6-4e7e-9ce8-60f7dfaa7a47@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <orvmuzXwlc90WDD6dL87STOeljMnNHGnAX1Ji2V7my8=.b202d5b4-22d6-4e7e-9ce8-60f7dfaa7a47@github.com>
Message-ID: <PB9RP-OKu5AKjA1dcVNoqT608tamUCQNfj1Gd5pNiG8=.56ddb425-593b-4d08-872e-a1d0b5ef9904@github.com>

On Fri, 21 Nov 2025 21:14:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment for negative K

Thanks for working on this! LGTM.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28195#pullrequestreview-3499763026

From dfuchs at openjdk.org  Mon Nov 24 11:15:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 11:15:48 GMT
Subject: RFR: 8372344: QUIC transfer may deadlock if pacing rate is too
 high
In-Reply-To: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
References: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
Message-ID: <iuZVPz8SSrQXF0HZGVWkv4_yfb380EFIo7W34r8jC70=.102a22a0-d65d-49db-8020-251dde8f6eb2@github.com>

On Fri, 21 Nov 2025 21:41:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Modify the PacketTransmissionTask to update the current deadline (`now`) between loop iterations.
> 
> This fixes the deadlock issue which happened when the next deadline was equal to the current one, but no progress could be made because the pacer quota only increases as time passes.
> 
> No new test; the issue was extremely rare. Existing tests continue to pass.

Changes look OK.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28462#pullrequestreview-3499822381

From dfuchs at openjdk.org  Mon Nov 24 11:23:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 11:23:57 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <8fEeWzy6eFREf_9w95BCagx2ovJzbIxsUUKIVNShB8E=.18bdad22-a48f-48db-93a3-4e05cd21d5a9@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
 <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
 <8fEeWzy6eFREf_9w95BCagx2ovJzbIxsUUKIVNShB8E=.18bdad22-a48f-48db-93a3-4e05cd21d5a9@github.com>
Message-ID: <Qqyu5VN8xwO2cV7mPNfCmtBu8TtTUOF-p4v1x41cVD4=.9c17a0ff-242d-42f3-9eda-aa990ac63e27@github.com>

On Mon, 24 Nov 2025 10:21:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http2TerminationCause.java line 268:
>> 
>>> 266:     private static final class InternalError extends Http2TerminationCause {
>>> 267:         private InternalError(final Throwable cause) {
>>> 268:             super(ErrorFrame.INTERNAL_ERROR, new Exception(cause));
>> 
>> why do we need to wrap the throwable here?
>
> I don't remember why I did that this way, but it looks like a leftover from my experiments. I've updated the PR to remove this wrapping. Thank you for catching this.

Good catch. Wrapping in plain Exception smells like debugging experiment :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555888489

From dfuchs at openjdk.org  Mon Nov 24 11:23:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 11:23:58 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <C-xWYuY73i_gp8ZDL-MKDxgAhUGiacitCvLf_EtlGgE=.bcb4ceae-068e-47fa-8a23-ec1705ac53a9@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
 <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
 <Mbso7De6ZMYmDANWsFMSxFpQOveHpgw-De-qBFNveQY=.d342b437-2673-4f94-b63b-dc62aec2a63a@github.com>
 <C-xWYuY73i_gp8ZDL-MKDxgAhUGiacitCvLf_EtlGgE=.bcb4ceae-068e-47fa-8a23-ec1705ac53a9@github.com>
Message-ID: <yh0hUIgrBu22Fi91D7zQrNPlJO6O92WPPpUche3VV88=.ff985650-c368-4b40-8bc5-8ea348fd2530@github.com>

On Mon, 24 Nov 2025 10:50:36 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Hello Daniel, my understanding is that the `HttpClient` default implementation in the JDK will be `jdk.internal.net.http.HttpClientImpl`, but if these tests are run against any other implementation of the `HttpClient` then this test is going to fail to find that internal state. If that isn't a practical concern, then I will go ahead and remove this skipping of the test.
>
> We don't have similar checks in any of the other whitebox tests, so I think we can safely assume that HttpClientImpl is the only implementation we test.

I agree - this is not a concern. Our tests only test our implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555878032

From jpai at openjdk.org  Mon Nov 24 11:26:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 11:26:42 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v11]
In-Reply-To: <yh0hUIgrBu22Fi91D7zQrNPlJO6O92WPPpUche3VV88=.ff985650-c368-4b40-8bc5-8ea348fd2530@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <E9NIc03HZMz3188GdFvE4dBPwaOvj6iMTSpjqsrBDIs=.62835c31-1fa5-45b7-963a-3010b8eda4b2@github.com>
 <NuYmeTj-NlpMV-CKapBYAvOJm7xHu6gImYY9eth8zWQ=.a3a3e02e-a928-481c-9041-d6592536dd2e@github.com>
 <Mbso7De6ZMYmDANWsFMSxFpQOveHpgw-De-qBFNveQY=.d342b437-2673-4f94-b63b-dc62aec2a63a@github.com>
 <C-xWYuY73i_gp8ZDL-MKDxgAhUGiacitCvLf_EtlGgE=.bcb4ceae-068e-47fa-8a23-ec1705ac53a9@github.com>
 <yh0hUIgrBu22Fi91D7zQrNPlJO6O92WPPpUche3VV88=.ff985650-c368-4b40-8bc5-8ea348fd2530@github.com>
Message-ID: <j-sdYoP4EuyaZ6TbZDKl6Fez3tlE_qimZz8ox1bgOZU=.88418ebd-deb4-4270-aca5-718cf4b058b1@github.com>

On Mon, 24 Nov 2025 11:18:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> We don't have similar checks in any of the other whitebox tests, so I think we can safely assume that HttpClientImpl is the only implementation we test.
>
> I agree - this is not a concern. Our tests only test our implementation.

Done - I've updated this test to no longer skip the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555905583

From jpai at openjdk.org  Mon Nov 24 11:26:41 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 11:26:41 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v13]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <BTlbr0OtPYZCT5YWksi6pTie3Rfb6iC-vFzJkMArrZo=.01d53bf9-6ba8-4f11-8e71-17ab41d3c036@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  test-only change - expect HttpClientImpl to be the underlying HttpClient implementation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/b7389dde..3885a5df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=11-12

  Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From djelinski at openjdk.org  Mon Nov 24 11:28:29 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 11:28:29 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v13]
In-Reply-To: <BTlbr0OtPYZCT5YWksi6pTie3Rfb6iC-vFzJkMArrZo=.01d53bf9-6ba8-4f11-8e71-17ab41d3c036@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BTlbr0OtPYZCT5YWksi6pTie3Rfb6iC-vFzJkMArrZo=.01d53bf9-6ba8-4f11-8e71-17ab41d3c036@github.com>
Message-ID: <XZS-VeNVA_9eEg4jc1uaZfFf3chpRn9HDgLMCn1iN-A=.e3623671-883b-4de0-b4af-8762b2ac8f29@github.com>

On Mon, 24 Nov 2025 11:26:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test-only change - expect HttpClientImpl to be the underlying HttpClient implementation

test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 125:

> 123:                      .build()) {
> 124:             // our test needs to peek into the internal field of jdk.internal.net.http.HttpClientImpl,
> 125:             // so we skip the test if the HttpClient isn't of the expected type

This comment is outdated now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555916283

From jpai at openjdk.org  Mon Nov 24 11:33:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 11:33:34 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v14]
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove outdated comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28233/files
  - new: https://git.openjdk.org/jdk/pull/28233/files/3885a5df..8c05d5eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28233&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28233/head:pull/28233

PR: https://git.openjdk.org/jdk/pull/28233

From jpai at openjdk.org  Mon Nov 24 11:33:36 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Nov 2025 11:33:36 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v13]
In-Reply-To: <XZS-VeNVA_9eEg4jc1uaZfFf3chpRn9HDgLMCn1iN-A=.e3623671-883b-4de0-b4af-8762b2ac8f29@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BTlbr0OtPYZCT5YWksi6pTie3Rfb6iC-vFzJkMArrZo=.01d53bf9-6ba8-4f11-8e71-17ab41d3c036@github.com>
 <XZS-VeNVA_9eEg4jc1uaZfFf3chpRn9HDgLMCn1iN-A=.e3623671-883b-4de0-b4af-8762b2ac8f29@github.com>
Message-ID: <u8-if_DNNeFcndJO012txiT95MpaaGKPgQvkfTJzLOQ=.76a3413f-e0e4-4273-b0c6-08125384d828@github.com>

On Mon, 24 Nov 2025 11:26:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test-only change - expect HttpClientImpl to be the underlying HttpClient implementation
>
> test/jdk/java/net/httpclient/http2/BurstyRequestsTest.java line 125:
> 
>> 123:                      .build()) {
>> 124:             // our test needs to peek into the internal field of jdk.internal.net.http.HttpClientImpl,
>> 125:             // so we skip the test if the HttpClient isn't of the expected type
> 
> This comment is outdated now.

I've pushed an update now. Sorry about this oversight, I've been switching back and forth between branches and missed these tiny details.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28233#discussion_r2555938180

From djelinski at openjdk.org  Mon Nov 24 11:37:21 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 11:37:21 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v14]
In-Reply-To: <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
Message-ID: <oQB1nWHdFsc3VmgYzUSG2doZMu5TwbyzRechbpKbC4E=.5a624ae5-e11c-42af-9c9d-859eeadb8977@github.com>

On Mon, 24 Nov 2025 11:33:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove outdated comment

LGTM. Thanks!

-------------

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28233#pullrequestreview-3499949652

From vyazici at openjdk.org  Mon Nov 24 11:39:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 11:39:20 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures should
 be converted to ProtocolException
Message-ID: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>

Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.

-------------

Commit messages:
 - Improve reuse
 - Improve wording in test
 - Improve wording in test
 - Guard `firstValueAsLong()` usages
 - Assert thrown exception types
 - Convert to JUnit
 - Add QPACK crash course

Changes: https://git.openjdk.org/jdk/pull/28431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369595
  Stats: 653 lines in 7 files changed: 234 ins; 128 del; 291 mod
  Patch: https://git.openjdk.org/jdk/pull/28431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28431/head:pull/28431

PR: https://git.openjdk.org/jdk/pull/28431

From djelinski at openjdk.org  Mon Nov 24 11:48:53 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 11:48:53 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <GfSPXhr3CkhTQSM_417XuJg7jOD6CiencqLFhXHyh2k=.9845eb21-1a9b-48c3-af44-5b3f747b8c41@github.com>

On Thu, 20 Nov 2025 13:10:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28430#pullrequestreview-3499998719

From djelinski at openjdk.org  Mon Nov 24 11:58:32 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 11:58:32 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v5]
In-Reply-To: <uyBg681teJF0RVBCCoZn2xY2NB4uIjDoIpgherxgbzs=.966f2e8d-7322-4fe1-9053-e846545c879f@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <uyBg681teJF0RVBCCoZn2xY2NB4uIjDoIpgherxgbzs=.966f2e8d-7322-4fe1-9053-e846545c879f@github.com>
Message-ID: <0ZUKZrijeF2VvV_jTTJFYNm0lm_WvL0y8SVE0v9YfOc=.9a7d18f5-a987-4344-a3a1-bfb80eefc4eb@github.com>

On Thu, 20 Nov 2025 12:21:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
>> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
>> This should be transparent for users of the API. 
>> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into SelectorManagerVT-8372159
>  - Copyright years
>  - Review feedback on test
>  - Revert changes to SelectorManager::shutdown
>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread

Marked as reviewed by djelinski (Reviewer).

test/jdk/java/net/httpclient/http3/H3QuicVTTest.java line 201:

> 199:     // This method attempts to determine whether the quic selector thread
> 200:     // is a platform thread or a virtual thread, and throws if expectations
> 201:     // ar not met.

Suggestion:

    // are not met.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28395#pullrequestreview-3500030651
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556019530

From dfuchs at openjdk.org  Mon Nov 24 12:08:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 12:08:34 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException
In-Reply-To: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
Message-ID: <7tSKH5aDzHaLWFrwH2w6OJNyJfTSnI3oLDcGWfLyxXI=.6d7ad994-7e72-42a6-995d-8c130aec5d62@github.com>

On Thu, 20 Nov 2025 14:13:50 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 284:

> 282:         long clen;
> 283:         try {
> 284:             clen = readContentLength(headers, "", 0);

This does not look right - we should keep -1 as meaning that content length was not found.

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 289:

> 287:         }
> 288: 
> 289:         // Read if there are and less than `MAX_IGNORE` bytes

some missing words here...

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 291:

> 289:         // Read if there are and less than `MAX_IGNORE` bytes
> 290:         if (clen > 0 && clen <= MAX_IGNORE) {
> 291:             return readBody(discarding(), !request.isWebSocket(), executor);

This does not look right, we should not close the connection if we have `Content-Length: 0`

src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1349:

> 1347:     // -- toAsciiString-like support to encode path and query URI segments
> 1348: 
> 1349:     public static Long readContentLength(HttpHeaders headers, String errorPrefix, long defaultIfMissing) throws ProtocolException {

I would prefer to use `OptionalLong` rather than nullable `Long`. Or maybe it's an oversight and the method is intended to return `long`? 
There seems to be quite some noise generated by trying to avoid using OptionalLong and I'm not sure I understand the reason.
Using Optional/OptionalLong makes it clearer whether the header was found or not.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28431#pullrequestreview-3500010745
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2556006255
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2556003159
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2556008868
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2556028080

From dfuchs at openjdk.org  Mon Nov 24 12:13:14 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 12:13:14 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v6]
In-Reply-To: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
Message-ID: <qjGnAoIrP9Em40_FPnA8vj1cZrFIgyL8YfUM0cZF5Gg=.5d538521-66fb-4937-a6d8-6ae01d035583@github.com>

> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
  
  Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28395/files
  - new: https://git.openjdk.org/jdk/pull/28395/files/d082d909..f2eebdc3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28395&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28395.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28395/head:pull/28395

PR: https://git.openjdk.org/jdk/pull/28395

From djelinski at openjdk.org  Mon Nov 24 12:23:31 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 12:23:31 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v6]
In-Reply-To: <POyghquA73E5_k3iKqZEGHCuu-se97Wm1kqlvTUuqbY=.77c9714a-8c4a-4e32-8bcf-71706f921919@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <POyghquA73E5_k3iKqZEGHCuu-se97Wm1kqlvTUuqbY=.77c9714a-8c4a-4e32-8bcf-71706f921919@github.com>
Message-ID: <8bHfiZThBv6oNAn_y-trnWR-LqxZRAXgDdHEbdtOQ4E=.7527f68f-9a7a-4140-b4fb-2bdb0e2573fd@github.com>

On Fri, 21 Nov 2025 20:14:53 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Updated SAN methods in CertificateBuilder to take multiple names
>  - Merge branch 'master' into update-md5-certs
>  - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
>  - removed unused keystore files, fixed certificate chain
>  - Merge branch 'master' into update-md5-certs
>  - changed line wrapping
>  - removed unnecessary comment and made getSSLContext(...) private
>  - changed tests to use SecurityUtils.removeDisabled*Algs methods
>  - fixed indents and copyright year
>  - Merge branch 'master' into update-md5-certs
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/904578e0...6579bc79

Please convert the IPAddressDNSIdentities test as well. It's expecting a handshake failure, but now it's passing for the wrong reasons. Other than that, LGTM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3570521948

From djelinski at openjdk.org  Mon Nov 24 12:25:30 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 12:25:30 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v6]
In-Reply-To: <qjGnAoIrP9Em40_FPnA8vj1cZrFIgyL8YfUM0cZF5Gg=.5d538521-66fb-4937-a6d8-6ae01d035583@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <qjGnAoIrP9Em40_FPnA8vj1cZrFIgyL8YfUM0cZF5Gg=.5d538521-66fb-4937-a6d8-6ae01d035583@github.com>
Message-ID: <Hv9aXP1PT-NBlO86cu0mxcXgIPpDTbxW7jGrKsaPQik=.727da9b0-344a-42cd-a385-1d84e2cbd888@github.com>

On Mon, 24 Nov 2025 12:13:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
>> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
>> This should be transparent for users of the API. 
>> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28395#pullrequestreview-3500115661

From dfuchs at openjdk.org  Mon Nov 24 14:10:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 14:10:31 GMT
Subject: Integrated: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread
In-Reply-To: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
Message-ID: <EwOJOdRtud-RvN67QLtw1tE8QWlczNSoae7ZrM6KG08=.0e405c6e-ebf2-4dce-80b6-bff02e7ccc51@github.com>

On Wed, 19 Nov 2025 15:56:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
> This should be transparent for users of the API. 
> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.

This pull request has now been integrated.

Changeset: aec54726
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aec54726df7efdea6f85ccd26763acb7ee839e2f
Stats:     298 lines in 9 files changed: 271 ins; 15 del; 12 mod

8372159: HttpClient SelectorManager thread could be a VirtualThread

Reviewed-by: djelinski

-------------

PR: https://git.openjdk.org/jdk/pull/28395

From dfuchs at openjdk.org  Mon Nov 24 14:25:12 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 14:25:12 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <i6L93o0UiGPy1uyuY1G99Sdor-xrr8rfgGSBt8IMvKE=.cb82ffba-304f-4d5b-8580-63468b0ab3ef@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - 8372198: Avoid closing PlainHttpConnection while holding a lock
 - Merge branch 'master' into SelectorManagerVT-8372159
 - Copyright years
 - Review feedback on test
 - Revert changes to SelectorManager::shutdown
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28430/files
  - new: https://git.openjdk.org/jdk/pull/28430/files/a8b1fb8d..a8b1fb8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Mon Nov 24 14:29:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 14:29:15 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v3]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <G1tBkvS1fVR38AFO5QnPwEH0iue1pDWWe84Vw4gYD-c=.322839f4-97d5-492a-aca5-e7347b5f9f67@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master
 - 8372198: Avoid closing PlainHttpConnection while holding a lock
 - Merge branch 'master' into SelectorManagerVT-8372159
 - Copyright years
 - Review feedback on test
 - Revert changes to SelectorManager::shutdown
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

-------------

Changes: https://git.openjdk.org/jdk/pull/28430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=02
  Stats: 48 lines in 3 files changed: 23 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From djelinski at openjdk.org  Mon Nov 24 15:11:36 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 15:11:36 GMT
Subject: RFR: 8371475: HttpClient: Implement CUBIC congestion controller
 [v6]
In-Reply-To: <orvmuzXwlc90WDD6dL87STOeljMnNHGnAX1Ji2V7my8=.b202d5b4-22d6-4e7e-9ce8-60f7dfaa7a47@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
 <orvmuzXwlc90WDD6dL87STOeljMnNHGnAX1Ji2V7my8=.b202d5b4-22d6-4e7e-9ce8-60f7dfaa7a47@github.com>
Message-ID: <xL9JBOWqD7ycggEqMT0ozyMRn1EIJSXRk-h_YpvAxzc=.fd50329b-a4f7-47e8-8f13-ef8920f5097f@github.com>

On Fri, 21 Nov 2025 21:14:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
>> 
>> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
>> 
>> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
>> 
>> A new test was added to exercise the new congestion controller. Existing tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment for negative K

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28195#issuecomment-3571249952

From djelinski at openjdk.org  Mon Nov 24 15:14:29 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 15:14:29 GMT
Subject: Integrated: 8371475: HttpClient: Implement CUBIC congestion controller
In-Reply-To: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
References: <59oCCI1a54k9zlR_GD1XmNoMKGVJUmvAmxnjyIuWStE=.df617ea4-d315-4a0f-a43a-46479b487eeb@github.com>
Message-ID: <tnic4w9Bp-F8mNFsBjfPGkhDsEDm7G2jhJeshJBn7xo=.bef00c5a-6922-44d7-b911-ac97666f26a6@github.com>

On Fri, 7 Nov 2025 13:38:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> CUBIC is a standard TCP congestion control algorithm that uses a cubic function instead of a linear congestion window increase function to improve scalability and stability over fast and long-distance networks. CUBIC has been adopted as the default TCP congestion control algorithm by the Linux, Windows, and Apple stacks.
> 
> This PR adds a new congestion controller algorithm. It reuses a large part of the QuicRenoCongestionController, which was refactored to two classes - QuicBaseCongestionController, containing the shared code, and QuicRenoCongestionController, containing only the code that is unique to Reno.
> 
> CUBIC is now the default congestion controller. Reno can still be selected by setting the system property `jdk.httpclient.quic.congestionController` to `reno`.
> 
> A new test was added to exercise the new congestion controller. Existing tests continue to pass.

This pull request has now been integrated.

Changeset: a091af1d
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a091af1db34bc9e1646b687aad7704c3105d7ec7
Stats:     1018 lines in 9 files changed: 756 ins; 254 del; 8 mod

8371475: HttpClient: Implement CUBIC congestion controller

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28195

From mdonovan at openjdk.org  Mon Nov 24 17:22:39 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Mon, 24 Nov 2025 17:22:39 GMT
Subject: RFR: 8353738: Update TLS unit tests to not use certificates with
 MD5 signatures [v7]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <DTog6sfC8efnL2ysENz2zRAVGWNuGZ7hfE8mxrwP1vo=.dcf5fc1f-9188-4fd4-a2c2-e0930d2c257d@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Updated IPAddressDNSIdentities and confirmed test fails for correct reason
 - Merge branch 'master' into update-md5-certs
 - Updated SAN methods in CertificateBuilder to take multiple names
 - Merge branch 'master' into update-md5-certs
 - removed IPIdentitites.java because it's identical to IPAddressIPIdenties; added IPv6 SAN ext
 - removed unused keystore files, fixed certificate chain
 - Merge branch 'master' into update-md5-certs
 - changed line wrapping
 - removed unnecessary comment and made getSSLContext(...) private
 - changed tests to use SecurityUtils.removeDisabled*Algs methods
 - ... and 3 more: https://git.openjdk.org/jdk/compare/cd9e5e5a...ea9c2dce

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/6579bc79..ea9c2dce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=05-06

  Stats: 1138 lines in 16 files changed: 412 ins; 630 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From djelinski at openjdk.org  Mon Nov 24 18:02:23 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 24 Nov 2025 18:02:23 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols configured
 disable HTTP2+ support
Message-ID: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>

When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.

This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.

Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.

-------------

Commit messages:
 - Do not require protocols in SSLParameters

Changes: https://git.openjdk.org/jdk/pull/28480/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28480&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371887
  Stats: 122 lines in 7 files changed: 70 ins; 39 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28480/head:pull/28480

PR: https://git.openjdk.org/jdk/pull/28480

From dfuchs at openjdk.org  Mon Nov 24 19:29:15 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 19:29:15 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <15AReOBUAseO-BiCWHW7N-OSOcknDc0Box3c90cXRZU=.5d7341db-94ea-4cdf-b3cd-fabe414dd88d@github.com>
Message-ID: <_SMDMjDoXuDI_Sujt62HD_YewzTQQlvqMSkpffJKq3A=.64a03981-30d1-48e5-a767-d4121c617296@github.com>

On Thu, 13 Nov 2025 09:27:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > > Some quick comments.
>>> > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>>> > 
>>> > 
>>> > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>>> 
>>> There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>> 
>> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?
>
>> > > > Some quick comments.
>> > > > We should be consistent in the naming, and rename `Halfloat*` to `Float16*`.
>> > > 
>> > > 
>> > > I concur, especially since there are multiple 16-bit floating-point formats in use including the IEEE 754 float16 as well as bfloat16.
>> > 
>> > 
>> > There are nomenclature issues that I am facing. Currently, all the Float16 concrete classes use the Halffloat prefix i.e., Halffloat64Vector, Halffloat128Vector; converting these to Float16 looks a little confusing, i.e., Float1664Vector, Float16128Vector, etc Kindly suggest a better name to represent these classes.
>> 
>> Maybe we move the shape to the end e.g., `Float16Vector128`, `IntVector128`, `IntVectorMax`?
> 
> This looks good, since all these are concrete vector classes not exposed to users.

@jatin-bhateja it looks like you should be merging latest changes from master; Some changes shown in the diff obviously do not belong to this fix:
https://github.com/openjdk/jdk/pull/28002/files#diff-7798f606ce2bbf96fd99999c8c0ef9a4bb0455c128dd7e1249dea8db23d35402
Hopefully merging latest changes from master will make them go away?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3571013379

From jbhateja at openjdk.org  Mon Nov 24 19:29:17 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Nov 2025 19:29:17 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
 <W3wLPA_gsj3C0nXvT2xQqIh5DlFJW0VszDQtmhkieJ0=.06dc05cd-c081-44f4-8fe5-e81c261dea8a@github.com>
 <xICotngWnv6o6yApK6uBKGMXro-V-x96TTZVZo3Jxx4=.f96530fe-491e-4caa-8d1a-9fff3018533f@github.com>
 <n7Xa6kvC3x_MgO9XMZjfJUdm0D30wsB-vYI-Ce3J3O4=.8c5ec613-3c86-49ba-87ab-d29d6be87b6f@github.com>
 <m3iiFd9268Wpp6ortuHKCEA7AwecpV22KL3UEi2E0XA=.a3920fc3-4a3e-47c2-a602-e72872560a40@github.com>
 <U8s19UjaUOh0ipUZeKkSAprwjOsFHHmNefi5AKcohSo=.0ba2cf00-29c4-41a6-b91c-65ff22e0ff92@github.com>
 <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com>
 <bvuVSZazvV1xkWXg36-aNiHcYGm7OtwESmohHSDy58w=.dae1caf9-c2b4-4527-b1fa-adf3c18dc366@github.com>
Message-ID: <ej2VU_26IZZBDgiGvry6djiDTMbjxH6XdqfgC0uuggc=.3e410400-d552-4721-8277-60eda5db7524@github.com>

On Thu, 13 Nov 2025 19:47:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
>
>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class.
>> 
>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable
> 
> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g.,  T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind.

Hi @PaulSandoz, I have addressed your comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3572377706

From jbhateja at openjdk.org  Mon Nov 24 19:29:14 2025
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 24 Nov 2025 19:29:14 GMT
Subject: RFR: 8370691: Add new Float16Vector type and enable
 intrinsification of vector operations supported by auto-vectorizer [v3]
In-Reply-To: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
References: <yk5cwKZgLTDLx__TO1vGfb6603H_Klt9vREaJAlSbPg=.c18f7e40-9474-442a-8dbd-0f3a5755aa22@github.com>
Message-ID: <6ma1bZs5YmEe_PtNmR69pVoJ_YAWy5fUQrsnnk8nH9M=.0594b623-f494-4af3-8e1c-f88120c53aca@github.com>

> Add a new  Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type.
> - Add necessary inline expander support.
>    - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA.
> - Use existing Float16 vector IR and backend support.
> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations.
>  
> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc).
> 
> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels.
> 
> <img width="1449" height="629" alt="image" src="https://github.com/user-attachments/assets/b4474361-9886-4315-a614-f4073fd075b9" />
> 
> Initial RFP[1] was floated on the panama-dev mailing list.
> 
> Kindly review the draft PR and share your feedback.
> 
> Best Regards,
> Jatin
> 
> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Cleanups
 - Adding support for custom basic  type T_FLOAT16, passing BasicType lane types to inline expander entries
 - Cleaning up interface as per review suggestions
 - Some cleanups
 - Fix some JTREG failures
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691
 - Revamped JTreg test generation and bug fixes
 - Cleanups
 - Removing redundant warmup constraint
 - ... and 5 more: https://git.openjdk.org/jdk/compare/8bafc2f0...f34d324f

-------------

Changes: https://git.openjdk.org/jdk/pull/28002/files
  Webrev: Webrev is not available because diff is too large
  Stats: 509516 lines in 232 files changed: 281237 ins; 226539 del; 1740 mod
  Patch: https://git.openjdk.org/jdk/pull/28002.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002

PR: https://git.openjdk.org/jdk/pull/28002

From dfuchs at openjdk.org  Mon Nov 24 19:53:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 24 Nov 2025 19:53:39 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into ConnectionCloseLock-8372198
 - Merge master
 - 8372198: Avoid closing PlainHttpConnection while holding a lock
 - Merge branch 'master' into SelectorManagerVT-8372159
 - Copyright years
 - Review feedback on test
 - Revert changes to SelectorManager::shutdown
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

-------------

Changes: https://git.openjdk.org/jdk/pull/28430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=03
  Stats: 48 lines in 3 files changed: 23 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From vyazici at openjdk.org  Mon Nov 24 20:18:21 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 20:18:21 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v6]
In-Reply-To: <qjGnAoIrP9Em40_FPnA8vj1cZrFIgyL8YfUM0cZF5Gg=.5d538521-66fb-4937-a6d8-6ae01d035583@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <qjGnAoIrP9Em40_FPnA8vj1cZrFIgyL8YfUM0cZF5Gg=.5d538521-66fb-4937-a6d8-6ae01d035583@github.com>
Message-ID: <Lv0_7BpWH4dKbF-H0Fubar2uQU1LauNqYYSwBhwDcck=.99919056-d760-4dca-a4bb-b03ccf142359@github.com>

On Mon, 24 Nov 2025 12:13:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Each HttpClient instance creates an additional platform thread for its SelectorManager. With recent updates to NIO/VirtualThreads that thread could now become a VirtualThread. This would avoid having each HttpClient instance use up one platform thread.
>> This is similar to what was done for the HttpClient QuicSelectorThread in [JDK-8369920](https://bugs.openjdk.org/browse/JDK-8369920).
>> This should be transparent for users of the API. 
>> An undocumented internal system property is introduced that can revert the change in case of unforeseen trouble.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>   
>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>

I had started my review in the morning, polished it in the evening, submitted, and then noticed it was already integrated. ? None of my remarks were a blocker. @dfuch, feel free to interpret them as you wish.

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1332:

> 1330:         String getName() {
> 1331:             return owner.selmgrThread.getName();
> 1332:         }

Where is this used?

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 55:

> 53:  *        jdk.httpclient.test.lib.common.HttpServerAdapters
> 54:  * @run junit/othervm
> 55:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors

@dfuch, double-checking: do we really want to keep `-Djdk.httpclient.HttpClient.log=...` configuration? They generally generate excessive output and consequently get truncated. Judging from my experience, we tend to increase logging verbosity of tests if there are intermittent failures, otherwise, if they pass, they better pass quietly? In short, I am not against adding them, but I prefer it to be a conscious decision, not a copy-paste leftover. ?

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 56:

> 54:  * @run junit/othervm
> 55:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
> 56:  *              H2SelectorVTTest

Suggestion:

 *              ${test.main.class}

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 69:

> 67:  *              -Djdk.internal.httpclient.tcp.selector.useVirtualThreads=never
> 68:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
> 69:  *              H2SelectorVTTest

Suggestion:

 *              ${test.main.class}

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 82:

> 80:  *              -Djdk.internal.httpclient.tcp.selector.useVirtualThreads=always
> 81:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
> 82:  *              H2SelectorVTTest

Suggestion:

 *              ${test.main.class}

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 95:

> 93:  *              -Djdk.internal.httpclient.tcp.selector.useVirtualThreads=default
> 94:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
> 95:  *              H2SelectorVTTest

Suggestion:

 *              ${test.main.class}

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 108:

> 106:  *              -Djdk.internal.httpclient.tcp.selector.useVirtualThreads=garbage
> 107:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
> 108:  *              H2SelectorVTTest

Suggestion:

 *              ${test.main.class}

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 113:

> 111: class H2SelectorVTTest implements HttpServerAdapters {
> 112: 
> 113:     private static SSLContext sslContext;

1. Is SSL necessary for this test?
2. Do we need two tests: with and without SSL?

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 147:

> 145:         h2Server.start();
> 146:         System.out.println("Server started at " + h2Server.getAddress());
> 147:         requestURI = "https://" + h2Server.serverAuthority() + "/hello";

I suggest salting the path (to avoid unintentionally getting responded by a foreign server) and suffixing the request URI with `/x` (to guard against [JDK-8272758]):

Suggestion:

        h2Server.addHandler((exchange) -> exchange.sendResponseHeaders(200, 0), "/H2SelectorVTTest");
        h2Server.start();
        System.out.println("Server started at " + h2Server.getAddress());
        requestURI = "https://" + h2Server.serverAuthority() + "/H2SelectorVTTest/x";


[JDK-8272758]: https://bugs.openjdk.org/browse/JDK-8272758

test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 201:

> 199:     // selector thread is a platform thread. Otherwise, it assumes
> 200:     // that the thread is virtual.
> 201:     private static void assertSelectorThread(HttpClient client) {

Since `SelectorManager` has been converted to a `Runnable`, would iterating through stack traces of existing platform threads and checking if any `StackTraceElement` matches `SelectorManager::run` qualify a more accurate check?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28395#issuecomment-3572548313
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556118575
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556146525
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556131588
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556134313
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556135012
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556136192
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556136716
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556153878
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2557546712
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2557594027

From vyazici at openjdk.org  Mon Nov 24 20:18:23 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 20:18:23 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v2]
In-Reply-To: <XTcMZSjZCbBIUkC-qGWAFjGpLrajrNn-9hddl1Mpl5M=.a609c482-2b58-4587-a7d8-27fdefd81d68@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <wNoNgBFXEjxjlqSeW2htrlXSHSRIDQwQebdPgpDnvLY=.163302ce-af32-4c2e-8133-8db702c1e3a1@github.com>
 <-c9sLQjtvr7t8k5_543O7oWJ5vy0PZj4Dsl_OMWmZNg=.98041893-2d49-4533-b8f2-f35f2838c127@github.com>
 <XTcMZSjZCbBIUkC-qGWAFjGpLrajrNn-9hddl1Mpl5M=.a609c482-2b58-4587-a7d8-27fdefd81d68@github.com>
Message-ID: <ETYRcXN1NRhC9edISlYdCqvKk3OtKEAl8kO9nPO9oFc=.9f108120-8e7e-4d5f-b930-4a164f7b12c1@github.com>

On Thu, 20 Nov 2025 09:58:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 131:
>> 
>>> 129: 
>>> 130:     static final UseVTForSelector USE_VT_FOR_SELECTOR =
>>> 131:         Utils.useVTForSelector("jdk.internal.httpclient.tcp.selector.useVirtualThreads", "default");
>> 
>> Hello Daniel, I vaguely remember we discussed whether or not to use a value called "default" for this property. But I don't remember what we decided. Looking at this now, I am wondering whether we should just do something like:
>> 
>> System.getProperty("jdk.internal.httpclient.tcp.selector.useVirtualThreads", "true")
>> 
>> to keep it simple?
>
> For tcp we only need true/false - but for quic we have a default behavior which depends on the platform. I decided to keep "always/never/default" for both properties for consistency. Let me think about it. I am not sure if that change (true/false for quic too) should be made in this PR.

[JDK-8369920] delivered in #27827 introduced


String useVtForSelector =
        System.getProperty("jdk.internal.httpclient.quic.selector.useVirtualThreads", "default");


26 window is closing, and I'm inclined to keep the properties aligned, that is, employ the always-never-default trichotomy. I can see the angle of @jaikiran; if a simpler true-false dichotomy fits the bill, let's go for it. But I'd appreciate it in a follow-up PR _and_ for both properties.

[JDK-8369920]: https://bugs.openjdk.org/browse/JDK-8369920

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2556108874

From vyazici at openjdk.org  Mon Nov 24 20:31:37 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 20:31:37 GMT
Subject: RFR: 8372344: QUIC transfer may deadlock if pacing rate is too
 high
In-Reply-To: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
References: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
Message-ID: <bllqra5WFo8rfBVy42g4w_WOIyv5e8RqbjN05b8n4Ys=.4bb8b8b9-9b4b-4e4f-a2bc-4eb904f11679@github.com>

On Fri, 21 Nov 2025 21:41:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Modify the PacketTransmissionTask to update the current deadline (`now`) between loop iterations.
> 
> This fixes the deadlock issue which happened when the next deadline was equal to the current one, but no progress could be made because the pacer quota only increases as time passes.
> 
> No new test; the issue was extremely rare. Existing tests continue to pass.

@djelinski, amazing catch! :exploding_head:

I'd really appreciate it if you can share a bit about how you troubleshoot it. Which diagnostics knobs did you turn? Which log patterns made you suspect the `congestionController.updatePacer(now)` line?

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28462#pullrequestreview-3502128029

From vyazici at openjdk.org  Mon Nov 24 20:45:27 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 20:45:27 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
Message-ID: <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>

> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Address review remarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28431/files
  - new: https://git.openjdk.org/jdk/pull/28431/files/700d6d4b..b491c9bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28431/head:pull/28431

PR: https://git.openjdk.org/jdk/pull/28431

From vyazici at openjdk.org  Mon Nov 24 20:45:31 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 20:45:31 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <7tSKH5aDzHaLWFrwH2w6OJNyJfTSnI3oLDcGWfLyxXI=.6d7ad994-7e72-42a6-995d-8c130aec5d62@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <7tSKH5aDzHaLWFrwH2w6OJNyJfTSnI3oLDcGWfLyxXI=.6d7ad994-7e72-42a6-995d-8c130aec5d62@github.com>
Message-ID: <b50kCDjOQ893ZMOyzIp3GM7rMNP8HVrKnmmf9ShXvkI=.609ff544-3809-465b-819a-0f94be517632@github.com>

On Mon, 24 Nov 2025 11:50:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review remarks
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 284:
> 
>> 282:         long clen;
>> 283:         try {
>> 284:             clen = readContentLength(headers, "", 0);
> 
> This does not look right - we should keep -1 as meaning that content length was not found.

I've updated it back to `-1` in b491c9bc98a.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 289:
> 
>> 287:         }
>> 288: 
>> 289:         // Read if there are and less than `MAX_IGNORE` bytes
> 
> some missing words here...

Fixed in b491c9bc98a.

> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 291:
> 
>> 289:         // Read if there are and less than `MAX_IGNORE` bytes
>> 290:         if (clen > 0 && clen <= MAX_IGNORE) {
>> 291:             return readBody(discarding(), !request.isWebSocket(), executor);
> 
> This does not look right, we should not close the connection if we have `Content-Length: 0`

I thought we don't need to read if `Content-Length: 0`. Anyway, reverted it in b491c9bc98a.

> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line 1349:
> 
>> 1347:     // -- toAsciiString-like support to encode path and query URI segments
>> 1348: 
>> 1349:     public static Long readContentLength(HttpHeaders headers, String errorPrefix, long defaultIfMissing) throws ProtocolException {
> 
> I would prefer to use `OptionalLong` rather than nullable `Long`. Or maybe it's an oversight and the method is intended to return `long`? 
> There seems to be quite some noise generated by trying to avoid using OptionalLong and I'm not sure I understand the reason.
> Using Optional/OptionalLong makes it clearer whether the header was found or not.

Good catch ? a leftover from an earlier refactoring. It can indeed be just `long` ? corrected in b491c9bc98a.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2557667860
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2557668092
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2557669354
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2557671333

From vyazici at openjdk.org  Mon Nov 24 21:12:34 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Mon, 24 Nov 2025 21:12:34 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support
In-Reply-To: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
Message-ID: <swW_yTcykNJVLbJ9RzsDbQf7EY3bmUmKGFvbuTq3AVc=.0850dc76-8bca-4146-83f4-5f2262e5a55d@github.com>

On Mon, 24 Nov 2025 17:52:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
> 
> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
> 
> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 472:

> 470:         }
> 471:         sslParams = requireNonNullElseGet(builder.sslParams, sslContext::getDefaultSSLParameters);
> 472:         String[] protocols = sslParams.getProtocols();

This is already a pretty large ctor ? can we rename this to `sslProtocols` to ease the cognitive load?

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 478:

> 476:         if (protocols == null) {
> 477:             // getDefaultSSLParameters.getProtocols should not return null
> 478:             protocols = new String[0];

This can be simplified to:

Suggestion:

            protocols = requireNonNullElseGet(sslContext.getDefaultSSLParameters().getProtocols(), new String[0]);

src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 1:

> 1: /*

Thank you, this was a long-overdue clean up. ? I had an earlier attempt at this in `HttpClientImpl::new`, but did not dare to extend its scope ? was told, _"There be dragons!"_ :rofl:

Curious: can we also clean up `QuicClient::requireTLS13` too? Personally, I'm very much in favor of seeing only one occurrence of hardcoded `"TLSv1.2"` and `"TLSv1.3"` string literals.

test/jdk/java/net/httpclient/TlsContextTest.java line 123:

> 121:     }
> 122: 
> 123:     private void runTest(SSLContext context, Version version, String expectedProtocol, boolean setParams) throws Exception {

_Nit:_ `s/setParams/setEmptyParams/`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2557696216
PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2557698850
PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2557710379
PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2557721461

From jpai at openjdk.org  Tue Nov 25 00:43:00 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 00:43:00 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v14]
In-Reply-To: <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
Message-ID: <sWPSOCSj39z9rjbFNDJ7pAQCRX97vpr25lUuxGeIM30=.a1b980ee-1e35-43be-bddd-336bfeb6d27a@github.com>

On Mon, 24 Nov 2025 11:33:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove outdated comment

Thank you Daniel for the review. Daniel, Volkan @dfuch @vy if this looks OK to you both too, then I'll go ahead and integrate this today. The tier tests continue to pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28233#issuecomment-3573290516

From jpai at openjdk.org  Tue Nov 25 06:40:58 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 06:40:58 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
Message-ID: <XbKh18J_DgoY7A7CrlTMAaHHuW2CIDsipBjC8eCxoO4=.a9c8c8ed-6e91-46d1-a4a8-f7846b1f6262@github.com>

On Mon, 24 Nov 2025 19:53:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into ConnectionCloseLock-8372198
>  - Merge master
>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>  - Merge branch 'master' into SelectorManagerVT-8372159
>  - Copyright years
>  - Review feedback on test
>  - Revert changes to SelectorManager::shutdown
>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread

src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 213:

> 211:             if (cleanup.isDone()) {
> 212:                 return;
> 213:             } else if (stopping = stopped) {

This is tricky to read. Should we change this to:

else if (stopped) {
   stopping = true;
   ....
}

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1356:

> 1354:             } finally {
> 1355:                 // cleanup anything that might have been left behind
> 1356:                 owner.stop();

Hello Daniel, since we already call `owner.stop()` unconditionally before the `try` block, is this second invocation of that method required?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2558717975
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2558712890

From vyazici at openjdk.org  Tue Nov 25 07:54:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 07:54:56 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v14]
In-Reply-To: <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
Message-ID: <SsQvbyVExZbYtnKdH4rmdxisZtskEEzxpV5DvOstJoU=.d344c051-6417-4b4f-8aee-a8a3bdd514fa@github.com>

On Mon, 24 Nov 2025 11:33:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove outdated comment

Marked as reviewed by vyazici (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28233#pullrequestreview-3503676518

From vyazici at openjdk.org  Tue Nov 25 08:26:36 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 08:26:36 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support
In-Reply-To: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
Message-ID: <3obBvMytOom0_0Yn2odu0amiM68wzEjvcDKwx8Ct_Zo=.6768aabe-55c4-4fbb-a8f5-c367545e1df2@github.com>

On Mon, 24 Nov 2025 17:52:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
> 
> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
> 
> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.

test/jdk/java/net/httpclient/http3/H3UnsupportedSSLParametersTest.java line 85:

> 83:      */
> 84:     @Test
> 85:     public void testDefault() throws Exception {

This test passes even without your changes. Is this expected?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2558964307

From djelinski at openjdk.org  Tue Nov 25 08:33:37 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 08:33:37 GMT
Subject: RFR: 8372344: QUIC transfer may deadlock if pacing rate is too
 high
In-Reply-To: <bllqra5WFo8rfBVy42g4w_WOIyv5e8RqbjN05b8n4Ys=.4bb8b8b9-9b4b-4e4f-a2bc-4eb904f11679@github.com>
References: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
 <bllqra5WFo8rfBVy42g4w_WOIyv5e8RqbjN05b8n4Ys=.4bb8b8b9-9b4b-4e4f-a2bc-4eb904f11679@github.com>
Message-ID: <SlbVY8xWXSepLYhP6RiugWsZSQ_TQgzFkKj3syZM89A=.110d4163-f0b8-47cc-88c8-dcfe5a144850@github.com>

On Mon, 24 Nov 2025 20:27:57 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Modify the PacketTransmissionTask to update the current deadline (`now`) between loop iterations.
>> 
>> This fixes the deadlock issue which happened when the next deadline was equal to the current one, but no progress could be made because the pacer quota only increases as time passes.
>> 
>> No new test; the issue was extremely rare. Existing tests continue to pass.
>
> @djelinski, amazing catch! :exploding_head:
> 
> I'd really appreciate it if you can share a bit about how you troubleshoot it. Which diagnostics knobs did you turn? Which log patterns made you suspect the `congestionController.updatePacer(now)` line?

@vy I observed a similar issue when I was writing the pacer code. There, the clock was actually running backwards, so it was happening more frequently, and was easier to catch using the quic:timer log. Here, adding any extra diagnostics changed the timing and made the issue go away, so I only measured the rtt and the pacing interval on a few machines, and found that at least in some cases the interval was in single nanosecond range.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28462#issuecomment-3574343060

From djelinski at openjdk.org  Tue Nov 25 08:34:59 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 08:34:59 GMT
Subject: Integrated: 8372344: QUIC transfer may deadlock if pacing rate is too
 high
In-Reply-To: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
References: <Jd1Yd3y-GWBgwxUybUbNpdWNfrxAG_UQtox4OGWjFnw=.5326b064-1fb4-4cde-9d45-e2c6afe7a6f1@github.com>
Message-ID: <aQm_EWsl09Bf_GXcHg6bkL-udjH4GdhVshv9qehM3V4=.642a9ab0-bea2-4028-8bc5-314b68875f06@github.com>

On Fri, 21 Nov 2025 21:41:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Modify the PacketTransmissionTask to update the current deadline (`now`) between loop iterations.
> 
> This fixes the deadlock issue which happened when the next deadline was equal to the current one, but no progress could be made because the pacer quota only increases as time passes.
> 
> No new test; the issue was extremely rare. Existing tests continue to pass.

This pull request has now been integrated.

Changeset: 34d6cc0d
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34d6cc0d89cbc840e8c358988c51e8d560b8dbb3
Stats:     10 lines in 1 file changed: 2 ins; 1 del; 7 mod

8372344: QUIC transfer may deadlock if pacing rate is too high

Reviewed-by: dfuchs, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/28462

From vyazici at openjdk.org  Tue Nov 25 09:38:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 09:38:46 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
Message-ID: <oKsXTGfIbGbEH5qEmAkmCLD2le9r1DAwAHFNU6FN164=.ce4cf436-2567-449e-8796-bb465ff45244@github.com>

On Mon, 24 Nov 2025 19:53:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into ConnectionCloseLock-8372198
>  - Merge master
>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>  - Merge branch 'master' into SelectorManagerVT-8372159
>  - Copyright years
>  - Review feedback on test
>  - Revert changes to SelectorManager::shutdown
>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread

src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 321:

> 319:         }
> 320:         try {
> 321:             tube.signalClosed(errorRef.get());

Shouldn't `errorRef.get()` be invoked in the synchronized block to ensure that the obtained `Throwable` is due to just executed lines above, and not overridden by a subsequent action?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2559267566

From vyazici at openjdk.org  Tue Nov 25 10:13:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 10:13:59 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
Message-ID: <vAtwnG2DrZD__DUDwR04EesuHJ4l86RzGEDcfmiO_Xo=.bc15a62c-d108-4c51-828f-8198cfa8317d@github.com>

On Mon, 24 Nov 2025 19:53:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into ConnectionCloseLock-8372198
>  - Merge master
>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>  - Merge branch 'master' into SelectorManagerVT-8372159
>  - Copyright years
>  - Review feedback on test
>  - Revert changes to SelectorManager::shutdown
>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread

I see the `noreg-hard` label. An approach that you might consider exploring:

1. Configure `jdk.httpclient.connectionPoolSize` to something really low (e.g., 1) to force `returnToPool()` to close excessive connections
2. Configure an `HttpTestServer` that blocks all `HttpTestExchange::sendResponseHeaders` behind a latch
3. Fire 100 `sendAsync().thenCompose(responseFutures::add)`, where `responseFutures` is an unbounded `BlockingQueue<HttpResponse>`
4. Release the `sendResponseHeaders` latch
5. Verify the success of the very first response, i.e., `responseFutures.enqueue()`
6. Shutdown the client without waiting for the rest of the responses to arrive
7. Wrap the test method in a `@RepeatedTest(50)`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28430#issuecomment-3574843187

From dfuchs at openjdk.org  Tue Nov 25 10:30:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 10:30:26 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <XbKh18J_DgoY7A7CrlTMAaHHuW2CIDsipBjC8eCxoO4=.a9c8c8ed-6e91-46d1-a4a8-f7846b1f6262@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
 <XbKh18J_DgoY7A7CrlTMAaHHuW2CIDsipBjC8eCxoO4=.a9c8c8ed-6e91-46d1-a4a8-f7846b1f6262@github.com>
Message-ID: <tND2Kfj8t2_weuDzpmdT4yfof4K7iWAJMoEaYJuobYU=.1dead17f-9067-44ff-89f9-092d8aad6a05@github.com>

On Tue, 25 Nov 2025 06:38:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into ConnectionCloseLock-8372198
>>  - Merge master
>>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>>  - Merge branch 'master' into SelectorManagerVT-8372159
>>  - Copyright years
>>  - Review feedback on test
>>  - Revert changes to SelectorManager::shutdown
>>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread
>
> src/java.net.http/share/classes/jdk/internal/net/http/ConnectionPool.java line 213:
> 
>> 211:             if (cleanup.isDone()) {
>> 212:                 return;
>> 213:             } else if (stopping = stopped) {
> 
> This is tricky to read. Should we change this to:
> 
> else if (stopped) {
>    stopping = true;
>    ....
> }

Not sure whether it's less tricky or more tricky. It kind of hides the fact that we assign stopping to stopped and that we read stopped (a volatile) only once to prevent reordering tricks that the compiler might play.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2559442973

From dfuchs at openjdk.org  Tue Nov 25 10:39:26 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 10:39:26 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <XbKh18J_DgoY7A7CrlTMAaHHuW2CIDsipBjC8eCxoO4=.a9c8c8ed-6e91-46d1-a4a8-f7846b1f6262@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
 <XbKh18J_DgoY7A7CrlTMAaHHuW2CIDsipBjC8eCxoO4=.a9c8c8ed-6e91-46d1-a4a8-f7846b1f6262@github.com>
Message-ID: <1p_LMoG5LYJ3m2CfkN72woCyCOlRLX9XrLKQaSktTcI=.36a6c104-4dd7-42a5-8ca1-0b3ca7002b9e@github.com>

On Tue, 25 Nov 2025 06:35:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into ConnectionCloseLock-8372198
>>  - Merge master
>>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>>  - Merge branch 'master' into SelectorManagerVT-8372159
>>  - Copyright years
>>  - Review feedback on test
>>  - Revert changes to SelectorManager::shutdown
>>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1356:
> 
>> 1354:             } finally {
>> 1355:                 // cleanup anything that might have been left behind
>> 1356:                 owner.stop();
> 
> Hello Daniel, since we already call `owner.stop()` unconditionally before the `try` block, is this second invocation of that method required?

stop() is reentrant not-reentrant :-) 
Calling it a second time means we're going to do a second sweep through the various list and close anything that might have sneaked through in between the first call and the time where `closed = true` was set. Remember - the purpose here is to close existing connections (which should all be idle in the pool) before closing the selector to prevent exceptions caused by the selector being thrown. Calling stop() a second time should be harmless.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2559471516

From dfuchs at openjdk.org  Tue Nov 25 10:39:28 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 10:39:28 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <oKsXTGfIbGbEH5qEmAkmCLD2le9r1DAwAHFNU6FN164=.ce4cf436-2567-449e-8796-bb465ff45244@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
 <oKsXTGfIbGbEH5qEmAkmCLD2le9r1DAwAHFNU6FN164=.ce4cf436-2567-449e-8796-bb465ff45244@github.com>
Message-ID: <CMm2tBkXHDbElvgBZ5_vxLqCnWrNZWID8I6qSu3HE_U=.f41552f8-526e-4fd7-8cb2-efd9e0cc947c@github.com>

On Tue, 25 Nov 2025 09:35:10 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into ConnectionCloseLock-8372198
>>  - Merge master
>>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>>  - Merge branch 'master' into SelectorManagerVT-8372159
>>  - Copyright years
>>  - Review feedback on test
>>  - Revert changes to SelectorManager::shutdown
>>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread
>
> src/java.net.http/share/classes/jdk/internal/net/http/PlainHttpConnection.java line 321:
> 
>> 319:         }
>> 320:         try {
>> 321:             tube.signalClosed(errorRef.get());
> 
> Shouldn't `errorRef.get()` be invoked in the synchronized block to ensure that the obtained `Throwable` is due to just executed lines above, and not overridden by a subsequent action?

errorRef is always set with compareAndSet(null, throwable) - so can't be changed once set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2559448340

From djelinski at openjdk.org  Tue Nov 25 10:46:34 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 10:46:34 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
Message-ID: <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>

> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
> 
> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
> 
> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.

Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:

 - Cleanup HttpClientImpl ctor
 - Rename setParams

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28480/files
  - new: https://git.openjdk.org/jdk/pull/28480/files/dc020b23..1c8ff94d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28480&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28480&range=00-01

  Stats: 12 lines in 2 files changed: 1 ins; 3 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/28480.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28480/head:pull/28480

PR: https://git.openjdk.org/jdk/pull/28480

From djelinski at openjdk.org  Tue Nov 25 10:46:35 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 10:46:35 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
Message-ID: <wnWb5e6qgOgqocvBwyhjr_4my3jqMskB-NE1H19XtMM=.c1fa9359-5a02-4017-a00e-270c4368492f@github.com>

On Tue, 25 Nov 2025 10:41:53 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
>> 
>> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
>> 
>> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup HttpClientImpl ctor
>  - Rename setParams

Thanks @vy for the review.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28480#pullrequestreview-3503972623

From djelinski at openjdk.org  Tue Nov 25 10:46:38 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 10:46:38 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <swW_yTcykNJVLbJ9RzsDbQf7EY3bmUmKGFvbuTq3AVc=.0850dc76-8bca-4146-83f4-5f2262e5a55d@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <swW_yTcykNJVLbJ9RzsDbQf7EY3bmUmKGFvbuTq3AVc=.0850dc76-8bca-4146-83f4-5f2262e5a55d@github.com>
Message-ID: <_hlSWTSm3QM9Y3VhrhOcdWUkuQ5CBQQQEsZtPF9F8v4=.1a8df07a-b710-464a-839a-2632481ce9d7@github.com>

On Mon, 24 Nov 2025 21:00:08 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Cleanup HttpClientImpl ctor
>>  - Rename setParams
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpConnection.java line 1:
> 
>> 1: /*
> 
> Thank you, this was a long-overdue clean up. ? I had an earlier attempt at this in `HttpClientImpl::new`, but did not dare to extend its scope ? was told, _"There be dragons!"_ :rofl:
> 
> Curious: can we also clean up `QuicClient::requireTLS13` too? Personally, I'm very much in favor of seeing only one occurrence of hardcoded `"TLSv1.2"` and `"TLSv1.3"` string literals.

That sounds like a larger change / cleanup. I'd rather not do it here.

> test/jdk/java/net/httpclient/http3/H3UnsupportedSSLParametersTest.java line 85:
> 
>> 83:      */
>> 84:     @Test
>> 85:     public void testDefault() throws Exception {
> 
> This test passes even without your changes. Is this expected?

Yes that's expected. The check in the HttpClientImpl was correct already. This just adds coverage.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2559427480
PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2559121009

From dfuchs at openjdk.org  Tue Nov 25 10:53:57 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 10:53:57 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v14]
In-Reply-To: <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
Message-ID: <fHyACCNkCIud-3hFEw4YSBi7iLqq12w2xaaKx0XlAcA=.7396020a-44b2-4e8e-a52d-18fd7b44ab23@github.com>

On Mon, 24 Nov 2025 11:33:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove outdated comment

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28233#pullrequestreview-3504484370

From dfuchs at openjdk.org  Tue Nov 25 11:06:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 11:06:21 GMT
Subject: RFR: 8372159: HttpClient SelectorManager thread could be a
 VirtualThread [v6]
In-Reply-To: <Lv0_7BpWH4dKbF-H0Fubar2uQU1LauNqYYSwBhwDcck=.99919056-d760-4dca-a4bb-b03ccf142359@github.com>
References: <423nOwPUu7g8ReBG902mAKLb709oJbbADXYDJbWrhOQ=.e2966b72-e4dc-4691-9c58-ce24e437c9f1@github.com>
 <qjGnAoIrP9Em40_FPnA8vj1cZrFIgyL8YfUM0cZF5Gg=.5d538521-66fb-4937-a6d8-6ae01d035583@github.com>
 <Lv0_7BpWH4dKbF-H0Fubar2uQU1LauNqYYSwBhwDcck=.99919056-d760-4dca-a4bb-b03ccf142359@github.com>
Message-ID: <309xe-PldrBIis-gx-igWu36q_Y-sjViSFAiyXVuAOY=.3297c56b-ee77-4e09-a3e6-ff22d2e1b98e@github.com>

On Mon, 24 Nov 2025 20:14:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/net/httpclient/http3/H3QuicVTTest.java
>>   
>>   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>
> I had started my review in the morning, polished it in the evening, submitted, and then noticed it was already integrated. ? None of my remarks were a blocker. @dfuch, feel free to interpret them as you wish.

Sorry @vy don't know what happened here: did you comment after I integrated the PR or was there a glitch with github/bots? I only saw your comments today.

> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 55:
> 
>> 53:  *        jdk.httpclient.test.lib.common.HttpServerAdapters
>> 54:  * @run junit/othervm
>> 55:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
> 
> @dfuch, double-checking: do we really want to keep `-Djdk.httpclient.HttpClient.log=...` configuration? They generally generate excessive output and consequently get truncated. Judging from my experience, we tend to increase logging verbosity of tests if there are intermittent failures, otherwise, if they pass, they better pass quietly? In short, I am not against adding them, but I prefer it to be a conscious decision, not a copy-paste leftover. ?

It's the debug logs that are verbose. 
`-Djdk.httpclient.HttpClient.log=requests,responses,headers,errors` should not flood the output unless you make 100's of requests.

> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 108:
> 
>> 106:  *              -Djdk.internal.httpclient.tcp.selector.useVirtualThreads=garbage
>> 107:  *              -Djdk.httpclient.HttpClient.log=requests,responses,headers,errors
>> 108:  *              H2SelectorVTTest
> 
> Suggestion:
> 
>  *              ${test.main.class}

Good point. Maybe in a followup.

> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 113:
> 
>> 111: class H2SelectorVTTest implements HttpServerAdapters {
>> 112: 
>> 113:     private static SSLContext sslContext;
> 
> 1. Is SSL necessary for this test?
> 2. Do we need two tests: with and without SSL?

One is enough - and using SSL makes it simpler (avoids the upgrade and ensure we're fully HTTP/2)

> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 147:
> 
>> 145:         h2Server.start();
>> 146:         System.out.println("Server started at " + h2Server.getAddress());
>> 147:         requestURI = "https://" + h2Server.serverAuthority() + "/hello";
> 
> I suggest salting the path (to avoid unintentionally getting responded by a foreign server) and suffixing the request URI with `/x` (to guard against [JDK-8272758]):
> 
> Suggestion:
> 
>         h2Server.addHandler((exchange) -> exchange.sendResponseHeaders(200, 0), "/H2SelectorVTTest");
>         h2Server.start();
>         System.out.println("Server started at " + h2Server.getAddress());
>         requestURI = "https://" + h2Server.serverAuthority() + "/H2SelectorVTTest/x";
> 
> 
> [JDK-8272758]: https://bugs.openjdk.org/browse/JDK-8272758

Could do that in a followup

> test/jdk/java/net/httpclient/http2/H2SelectorVTTest.java line 201:
> 
>> 199:     // selector thread is a platform thread. Otherwise, it assumes
>> 200:     // that the thread is virtual.
>> 201:     private static void assertSelectorThread(HttpClient client) {
> 
> Since `SelectorManager` has been converted to a `Runnable`, would iterating through stack traces of existing platform threads and checking if any `StackTraceElement` matches `SelectorManager::run` qualify a more accurate check?

Interesting idea. Would avoid the dependency on the thread name.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28395#issuecomment-3575057133
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2559556843
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2559557966
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2559553629
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2559551392
PR Review Comment: https://git.openjdk.org/jdk/pull/28395#discussion_r2559549151

From jpai at openjdk.org  Tue Nov 25 11:10:39 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 11:10:39 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
Message-ID: <q53DsiNe8PaVu1wocEzLzabHPoedWRMFqWujsKEsQKc=.cb6cc78d-d8bf-4c23-8729-44606f137e02@github.com>

On Tue, 25 Nov 2025 10:46:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
>> 
>> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
>> 
>> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup HttpClientImpl ctor
>  - Rename setParams

src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 480:

> 478:         hasRequiredH3TLS = Arrays.asList(sslProtocols).contains("TLSv1.3");
> 479:         // HTTP/2 MUST use TLS version 1.2 or higher for HTTP/2 over TLS
> 480:         hasRequiredH2TLS = hasRequiredH3TLS || Arrays.asList(sslProtocols).contains("TLSv1.2");

Hello Daniel, I think if a `HttpClient` is configured with `sslParameters(new SSLParameters())`, then even with this new change in this PR, where we default the `sslProtocols` here to `new String[0]`, `hasRequiredH2TLS` would continue to return `false` right? Thus H2 is still disabled?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2559575404

From jpai at openjdk.org  Tue Nov 25 11:18:02 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 11:18:02 GMT
Subject: RFR: 8326498: java.net.http.HttpClient connection leak using
 http/2 [v14]
In-Reply-To: <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
 <BU4kPnbtXY_ciNPhjyqm3p8fq9raQy3Rzd4o0AVp-hA=.a759aac8-3a85-42b5-bdc9-0cc4c272a106@github.com>
Message-ID: <Pw30ixK5tPVTN_xbv5uCWqWRf4SpqYI9z7hBkuDwLMc=.ee4dc288-3a3c-4025-b643-b3d782ac9a7a@github.com>

On Mon, 24 Nov 2025 11:33:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
>> 
>> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
>> 
>> A new jtreg test has been introduced which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove outdated comment

Thank you all for the thorough reviews and inputs. This is a reasonably big (but necessary) change in the connection termination code of HTTP/2, so these inputs were very useful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28233#issuecomment-3575093410

From jpai at openjdk.org  Tue Nov 25 11:18:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 11:18:03 GMT
Subject: Integrated: 8326498: java.net.http.HttpClient connection leak using
 http/2
In-Reply-To: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
References: <nS0v0Xl9i6OWW50GWp3P7CyOEs41-NXaoAfYXMKqCC4=.aee6a4b4-a1ce-4778-99b9-73d38c624884@github.com>
Message-ID: <B5r_JVmosMikJanJgozzyQR2ARCcOnhVj8cjj62Wj8Q=.331233ea-164c-42c1-a57a-c3abe7cb7979@github.com>

On Tue, 11 Nov 2025 12:58:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this fix which addresses a connection leak in HttpClient when dealing with HTTP/2 requests?
> 
> I have added a comment in https://bugs.openjdk.org/browse/JDK-8326498 which explains what the issue is. The fix here addresses the issue by cleaning up the `Http2Connection` closing logic and centralizing it to a connection terminator. The terminator then ensures that the right resources are closed (including the underlying SocketChannel) when the termination happens.
> 
> A new jtreg test has been introduced which reproduces the issue and verifies the fix.

This pull request has now been integrated.

Changeset: c19b1292
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c19b12927d2ac901ec8ccaa2de5897ee4c47af56
Stats:     993 lines in 10 files changed: 723 ins; 144 del; 126 mod

8326498: java.net.http.HttpClient connection leak using http/2

Reviewed-by: vyazici, djelinski, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28233

From djelinski at openjdk.org  Tue Nov 25 12:21:42 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 12:21:42 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <q53DsiNe8PaVu1wocEzLzabHPoedWRMFqWujsKEsQKc=.cb6cc78d-d8bf-4c23-8729-44606f137e02@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
 <q53DsiNe8PaVu1wocEzLzabHPoedWRMFqWujsKEsQKc=.cb6cc78d-d8bf-4c23-8729-44606f137e02@github.com>
Message-ID: <2BgUz0oFnHdlXl2V6rzvrOsbst1OEaighBViKn-2hA4=.382699f2-4efb-4ed4-bfb5-20509127ed51@github.com>

On Tue, 25 Nov 2025 11:08:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Cleanup HttpClientImpl ctor
>>  - Rename setParams
>
> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 480:
> 
>> 478:         hasRequiredH3TLS = Arrays.asList(sslProtocols).contains("TLSv1.3");
>> 479:         // HTTP/2 MUST use TLS version 1.2 or higher for HTTP/2 over TLS
>> 480:         hasRequiredH2TLS = hasRequiredH3TLS || Arrays.asList(sslProtocols).contains("TLSv1.2");
> 
> Hello Daniel, I think if a `HttpClient` is configured with `sslParameters(new SSLParameters())`, then even with this new change in this PR, where we default the `sslProtocols` here to `new String[0]`, `hasRequiredH2TLS` would continue to return `false` right? Thus H2 is still disabled?

Hi Jaikiran, we default the protocols to `sslContext.getDefaultSSLParameters().getProtocols()` which are documented to be always non-null for compliant SSLContext implementations. The fallback to `new String[0]` is only used for non-compliant SSLContexts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2559789114

From djelinski at openjdk.org  Tue Nov 25 12:48:16 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 25 Nov 2025 12:48:16 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
Message-ID: <1FkKHl2AQGDBi9pPmAXgrzZeo8BllUBcBgipDtS8X2g=.031489e1-fd58-4df8-8ecc-280ab2ce2173@github.com>

On Mon, 24 Nov 2025 20:45:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review remarks

src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 338:

> 336:         // expect-continue reads headers and body twice.
> 337:         // if we reach here, we must reset the headersReader state.
> 338:         finally {

Is this `finally` necessary? The `ProtocolException` is supposed to kill the connection anyway, so its internal state shouldn't matter much.

If it does matter, please move the `finally` to the closing brace of the `catch`; it looks odd now.

src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 374:

> 372:         // Check `Transfer-Encoding`
> 373:         var transferEncoding = headers.firstValue("Transfer-Encoding").orElse(null);
> 374:         if (transferEncoding != null) {

use `isPresent` instead of `orElse(null) != null`

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1822:

> 1820:     }
> 1821: 
> 1822:     private static int readStatusCode(HttpHeaders headers, String errorPrefix) throws ProtocolException {

There's a similar piece of code for HTTP3 [here](https://github.com/openjdk/jdk/blob/b491c9bc98a8da0a1d913e85673087e1b929cb3d/src/java.net.http/share/classes/jdk/internal/net/http/Http3Stream.java#L610-L624); do you think you could merge them?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2559547910
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2559710182
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2559813988

From jpai at openjdk.org  Tue Nov 25 13:12:21 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 13:12:21 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
Message-ID: <iI_by8dGoAtUNe1Ha4gFand4hLuSQ4gzs85JyBJlN68=.2b2bbe62-b34f-4321-af31-70e131478845@github.com>

On Tue, 25 Nov 2025 10:46:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
>> 
>> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
>> 
>> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup HttpClientImpl ctor
>  - Rename setParams

These changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28480#pullrequestreview-3505004311

From jpai at openjdk.org  Tue Nov 25 13:12:23 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Nov 2025 13:12:23 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <2BgUz0oFnHdlXl2V6rzvrOsbst1OEaighBViKn-2hA4=.382699f2-4efb-4ed4-bfb5-20509127ed51@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
 <q53DsiNe8PaVu1wocEzLzabHPoedWRMFqWujsKEsQKc=.cb6cc78d-d8bf-4c23-8729-44606f137e02@github.com>
 <2BgUz0oFnHdlXl2V6rzvrOsbst1OEaighBViKn-2hA4=.382699f2-4efb-4ed4-bfb5-20509127ed51@github.com>
Message-ID: <_oc9VOS7qls--jheBRZphZOZLOOnffC4YjEq-APB7Lc=.cb2bcf5a-934a-431b-aa5b-c10677c72503@github.com>

On Tue, 25 Nov 2025 12:18:30 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 480:
>> 
>>> 478:         hasRequiredH3TLS = Arrays.asList(sslProtocols).contains("TLSv1.3");
>>> 479:         // HTTP/2 MUST use TLS version 1.2 or higher for HTTP/2 over TLS
>>> 480:         hasRequiredH2TLS = hasRequiredH3TLS || Arrays.asList(sslProtocols).contains("TLSv1.2");
>> 
>> Hello Daniel, I think if a `HttpClient` is configured with `sslParameters(new SSLParameters())`, then even with this new change in this PR, where we default the `sslProtocols` here to `new String[0]`, `hasRequiredH2TLS` would continue to return `false` right? Thus H2 is still disabled?
>
> Hi Jaikiran, we default the protocols to `sslContext.getDefaultSSLParameters().getProtocols()` which are documented to be always non-null for compliant SSLContext implementations. The fallback to `new String[0]` is only used for non-compliant SSLContexts.

That helped. I understand this change better now. I hadn't paid attention that we are now passing `sslContext.getDefaultSSLParameters().getProtocols()` to the `requireNonNullElseGet` method:


requireNonNullElseGet(sslContext.getDefaultSSLParameters().getProtocols(), ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28480#discussion_r2559931418

From dfuchs at openjdk.org  Tue Nov 25 13:14:39 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 13:14:39 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <1FkKHl2AQGDBi9pPmAXgrzZeo8BllUBcBgipDtS8X2g=.031489e1-fd58-4df8-8ecc-280ab2ce2173@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
 <1FkKHl2AQGDBi9pPmAXgrzZeo8BllUBcBgipDtS8X2g=.031489e1-fd58-4df8-8ecc-280ab2ce2173@github.com>
Message-ID: <wZGo3HBV3JMhxepW5wVtjmk5jgL6UGShaPpr_6mPAhs=.3d9d56de-225b-4808-b033-f53f5e72efd2@github.com>

On Tue, 25 Nov 2025 10:59:10 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review remarks
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 338:
> 
>> 336:         // expect-continue reads headers and body twice.
>> 337:         // if we reach here, we must reset the headersReader state.
>> 338:         finally {
> 
> Is this `finally` necessary? The `ProtocolException` is supposed to kill the connection anyway, so its internal state shouldn't matter much.
> 
> If it does matter, please move the `finally` to the closing brace of the `catch`; it looks odd now.

Agreed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2559891925

From dfuchs at openjdk.org  Tue Nov 25 13:14:43 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 13:14:43 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
Message-ID: <eZZRfvfWKRYzRT-rLe_Rc9hs2HW3KvDWI8AQLrGUpps=.d5f91104-3352-44f2-8acb-1c6e864407b8@github.com>

On Mon, 24 Nov 2025 20:45:27 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.
>
> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review remarks

src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java line 1289:

> 1287:         // Read & validate `Content-Length`
> 1288:         long clen = readContentLength(
> 1289:                 promiseHeaders, "illegal push headers for pushId=%s: ".formatted(pushId), 0);

Let's keep -1 as default value to represent no Content-length header, even though not strictly necessary in this context.

src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1786:

> 1784:                    sure code up the stack handles NFE correctly. */
> 1785:                 responseHeaders.firstValueAsLong("content-length");
> 1786: 

We no longer check here that content-length is a number if present. Has that become unecessary?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2559898415
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2559924070

From dfuchs at openjdk.org  Tue Nov 25 14:03:21 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 14:03:21 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
Message-ID: <YkvxQmXi6rUn8GM9eo8QhfILCOCBqBE1YgCUo9fOx8s=.7f498d99-4919-43f0-a3f4-a07efa4a5054@github.com>

On Tue, 25 Nov 2025 10:46:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
>> 
>> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
>> 
>> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup HttpClientImpl ctor
>  - Rename setParams

Looks reasonable

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28480#pullrequestreview-3505220468

From dfuchs at openjdk.org  Tue Nov 25 14:44:04 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 14:44:04 GMT
Subject: RFR: 8372409:
 java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out
 during warmup
Message-ID: <tygDWjw3cTzV4SdBUuvbrpZhTTt4MO0ZYvphWLxrufA=.e7158864-4a13-4ac6-b404-29624aac8637@github.com>

The issue here occurs when the connection gets closed just before the `Http3ExchangeImpl` gets created. In that case the h3 stream reference counter gets incremented, but due to the connection being already closed Http3ExchangeImpl::close will not be invoked, even though the CF returned to the user has been correctly completed with the appropriate exception. Not calling `Http3ExchangeImpl::close` after the reference counter has been incremented prevents that reference counter from being properly decremented. This in turn causes `HttpClient::close()` to wait forever.

The fix is to double-check that the connection is still open after having added the exchange to the connection's exchange map. If the connection is still opened, we can start the exchange. Otherwise we mark it as unprocessed and close it.

-------------

Commit messages:
 - 8372409: java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out during warmup

Changes: https://git.openjdk.org/jdk/pull/28494/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28494&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372409
  Stats: 26 lines in 2 files changed: 21 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28494.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28494/head:pull/28494

PR: https://git.openjdk.org/jdk/pull/28494

From dfuchs at openjdk.org  Tue Nov 25 16:44:51 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 16:44:51 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v5]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <blRE6ab0W50S6KPCrVHJ0dSKgmv-bE3nWsd9slqUyWE=.e10918c0-4bd0-49b0-90a0-50fe89e9ff64@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Review feedback: added a test
 - Merge branch 'master' into ConnectionCloseLock-8372198
 - Merge branch 'master' into ConnectionCloseLock-8372198
 - Merge master
 - 8372198: Avoid closing PlainHttpConnection while holding a lock
 - Merge branch 'master' into SelectorManagerVT-8372159
 - Copyright years
 - Review feedback on test
 - Revert changes to SelectorManager::shutdown
 - 8372159: HttpClient SelectorManager thread could be a VirtualThread

-------------

Changes: https://git.openjdk.org/jdk/pull/28430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=04
  Stats: 276 lines in 4 files changed: 251 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Tue Nov 25 16:44:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 16:44:55 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
Message-ID: <PwBbXZEG1pXi4X_KRiRTflW4HALPoZeTBSmD9JD_aLM=.2560acf8-f325-462c-891c-3734d06478d9@github.com>

On Mon, 24 Nov 2025 19:53:39 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into ConnectionCloseLock-8372198
>  - Merge master
>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>  - Merge branch 'master' into SelectorManagerVT-8372159
>  - Copyright years
>  - Review feedback on test
>  - Revert changes to SelectorManager::shutdown
>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread

I added a test - but so far I haven't been able to make it fail locally, with or without the fix. I sent the test to the CI - will see how it goes there...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28430#issuecomment-3576556472

From dfuchs at openjdk.org  Tue Nov 25 18:49:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 18:49:40 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v6]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <9UaZm60WghyK8-hMRWwdmtWzX8hMT0jBh5vYY6LQD5w=.aaf40131-8a63-41ae-9cc1-03bf15d0fe78@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  test updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28430/files
  - new: https://git.openjdk.org/jdk/pull/28430/files/2d2c79e4..56643d23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=04-05

  Stats: 26 lines in 1 file changed: 13 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Tue Nov 25 19:30:31 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 25 Nov 2025 19:30:31 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v7]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <gwBDo4jRW1Dda-eIVVwtztwtJ1i0zNEeCXqiqKQoffA=.3a7cf386-3dbf-4e91-a342-8f2123ce57af@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  More test updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28430/files
  - new: https://git.openjdk.org/jdk/pull/28430/files/56643d23..5bbe9042

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=05-06

  Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From vyazici at openjdk.org  Tue Nov 25 21:04:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 21:04:42 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <eZZRfvfWKRYzRT-rLe_Rc9hs2HW3KvDWI8AQLrGUpps=.d5f91104-3352-44f2-8acb-1c6e864407b8@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
 <eZZRfvfWKRYzRT-rLe_Rc9hs2HW3KvDWI8AQLrGUpps=.d5f91104-3352-44f2-8acb-1c6e864407b8@github.com>
Message-ID: <2yWFGciKBlvtLnh4ElKZo1-WWCqcvBaCZYbMs4pogOY=.1562cad3-bd33-419e-9744-abbbc89abcdc@github.com>

On Tue, 25 Nov 2025 13:05:38 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review remarks
>
> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1786:
> 
>> 1784:                    sure code up the stack handles NFE correctly. */
>> 1785:                 responseHeaders.firstValueAsLong("content-length");
>> 1786: 
> 
> We no longer check here that content-length is a number if present. Has that become unecessary?

This is a fast-path to exit early if `Content-Length` is present and cannot be parsed into a `long`. AFAICT,

- The author was already either aware of the missing `Content-Length` checks, or suspecting that. Therefore he introduced this rudimentary check.
- This concern is only relevant for `Content-Length` consumers, where we thoroughly validate the value at each use-site in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2561394004

From vyazici at openjdk.org  Tue Nov 25 21:10:42 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 21:10:42 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v3]
In-Reply-To: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
Message-ID: <me2uiFsPvB3FGDmvIeIx1dcGTizX7VP36UGxuBWKs2Y=.f6157508-ba8f-4971-ad12-b8abb9734a8c@github.com>

> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.

Volkan Yazici has updated the pull request incrementally with four additional commits since the last revision:

 - Remove redundant `finally`
 - Use `-1` as default in `Http3ExchangeImpl`
 - Use `readStatusCode()` in `Http3Stream`
 - Replace `orElse(null)` with `Optional` usage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28431/files
  - new: https://git.openjdk.org/jdk/pull/28431/files/b491c9bc..0c384717

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=01-02

  Stats: 63 lines in 6 files changed: 23 ins; 31 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28431/head:pull/28431

PR: https://git.openjdk.org/jdk/pull/28431

From vyazici at openjdk.org  Tue Nov 25 21:10:44 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 21:10:44 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <wZGo3HBV3JMhxepW5wVtjmk5jgL6UGShaPpr_6mPAhs=.3d9d56de-225b-4808-b033-f53f5e72efd2@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
 <1FkKHl2AQGDBi9pPmAXgrzZeo8BllUBcBgipDtS8X2g=.031489e1-fd58-4df8-8ecc-280ab2ce2173@github.com>
 <wZGo3HBV3JMhxepW5wVtjmk5jgL6UGShaPpr_6mPAhs=.3d9d56de-225b-4808-b033-f53f5e72efd2@github.com>
Message-ID: <cjdRmQ0lQkgqhrl3E8qpBAfZRdpdkIs_0jo8hPIx0G0=.8ce9ebd6-b242-48cc-a402-7eaf52d49f7f@github.com>

On Tue, 25 Nov 2025 12:54:55 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http1Response.java line 338:
>> 
>>> 336:         // expect-continue reads headers and body twice.
>>> 337:         // if we reach here, we must reset the headersReader state.
>>> 338:         finally {
>> 
>> Is this `finally` necessary? The `ProtocolException` is supposed to kill the connection anyway, so its internal state shouldn't matter much.
>> 
>> If it does matter, please move the `finally` to the closing brace of the `catch`; it looks odd now.
>
> Agreed.

Removed `finally` in 0c384717700.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2561403840

From vyazici at openjdk.org  Tue Nov 25 21:10:46 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 21:10:46 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <eZZRfvfWKRYzRT-rLe_Rc9hs2HW3KvDWI8AQLrGUpps=.d5f91104-3352-44f2-8acb-1c6e864407b8@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
 <eZZRfvfWKRYzRT-rLe_Rc9hs2HW3KvDWI8AQLrGUpps=.d5f91104-3352-44f2-8acb-1c6e864407b8@github.com>
Message-ID: <p9lqxfcEKw6jo1kmbgWfyopoWNufyA-VMylB7-Y5xwA=.7ed06eb8-3487-4160-981d-bf7f526717da@github.com>

On Tue, 25 Nov 2025 12:57:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review remarks
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java line 1289:
> 
>> 1287:         // Read & validate `Content-Length`
>> 1288:         long clen = readContentLength(
>> 1289:                 promiseHeaders, "illegal push headers for pushId=%s: ".formatted(pushId), 0);
> 
> Let's keep -1 as default value to represent no Content-length header, even though not strictly necessary in this context.

Changed as requested in dab06dea528.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2561404387

From vyazici at openjdk.org  Tue Nov 25 21:10:48 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 25 Nov 2025 21:10:48 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v2]
In-Reply-To: <1FkKHl2AQGDBi9pPmAXgrzZeo8BllUBcBgipDtS8X2g=.031489e1-fd58-4df8-8ecc-280ab2ce2173@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
 <1FkKHl2AQGDBi9pPmAXgrzZeo8BllUBcBgipDtS8X2g=.031489e1-fd58-4df8-8ecc-280ab2ce2173@github.com>
Message-ID: <PC10c9RsOvsAPjPNFCV4v_X8hU4mP4CJrRfIMNNP4S4=.baa84742-6235-4af0-aaea-f94eb044e489@github.com>

On Tue, 25 Nov 2025 11:52:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review remarks
>
> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 374:
> 
>> 372:         // Check `Transfer-Encoding`
>> 373:         var transferEncoding = headers.firstValue("Transfer-Encoding").orElse(null);
>> 374:         if (transferEncoding != null) {
> 
> use `isPresent` instead of `orElse(null) != null`

Changed as requested in f01368f08c9.

> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1822:
> 
>> 1820:     }
>> 1821: 
>> 1822:     private static int readStatusCode(HttpHeaders headers, String errorPrefix) throws ProtocolException {
> 
> There's a similar piece of code for HTTP3 [here](https://github.com/openjdk/jdk/blob/b491c9bc98a8da0a1d913e85673087e1b929cb3d/src/java.net.http/share/classes/jdk/internal/net/http/Http3Stream.java#L610-L624); do you think you could merge them?

This was the case, but apparently got lost during refactoring. In dfbb64913f0,

- I've moved `readStatusCode` to `Utils`
- Replaced `i < 0` check of `readStatusCode` with `i < 100 || i > 999`
- Used `readStatusCode` in `Http3Stream`

Searched for `":status"` (and `Content-Length`) in `src/java.net.http` and could not find any other hits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2561404031
PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2561404220

From ehs122100 at gmail.com  Wed Nov 26 00:38:38 2025
From: ehs122100 at gmail.com (=?utf-8?B?7J2A7ZiE7IiY?=)
Date: Wed, 26 Nov 2025 09:38:38 +0900
Subject: 8371903: HttpClient GOAWAY error handling - work status inquiry
Message-ID: <1C8FA4B2-E1C2-48AF-A82F-D2D11FEAE2EE@gmail.com>

Hi,

I would like to contribute to JDK-8371903 (improving handling of 
HTTP/2 GOAWAY frames with error codes in HttpClient).

I noticed that Daniel Jelinski is assigned to this issue. I wanted 
to check if work is currently in progress. If available, I would 
like to work on this issue and submit a PR.

Please let me know if this is possible.

Thanks,
hyunsuEun

From vyazici at openjdk.org  Wed Nov 26 09:35:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 26 Nov 2025 09:35:55 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v4]
In-Reply-To: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
Message-ID: <28qWETUXWavtOeUKc8s3oDEyDbrOQEBsIVBoI1G40l0=.a1503cad-a240-414e-97ec-cd71eb2ae854@github.com>

> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Document `Http1Response::ignoreBody`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28431/files
  - new: https://git.openjdk.org/jdk/pull/28431/files/0c384717..d2d9adfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=02-03

  Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28431/head:pull/28431

PR: https://git.openjdk.org/jdk/pull/28431

From vyazici at openjdk.org  Wed Nov 26 10:10:58 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 26 Nov 2025 10:10:58 GMT
Subject: RFR: 8372409:
 java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out
 during warmup
In-Reply-To: <tygDWjw3cTzV4SdBUuvbrpZhTTt4MO0ZYvphWLxrufA=.e7158864-4a13-4ac6-b404-29624aac8637@github.com>
References: <tygDWjw3cTzV4SdBUuvbrpZhTTt4MO0ZYvphWLxrufA=.e7158864-4a13-4ac6-b404-29624aac8637@github.com>
Message-ID: <PURaIzDZyKGfMnVCKQ8lcm9BHDJDyNtGf7IfcGM0ku8=.420b96fb-5695-4606-86f7-8c0b651c2bbd@github.com>

On Tue, 25 Nov 2025 14:38:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The issue here occurs when the connection gets closed just before the `Http3ExchangeImpl` gets created. In that case the h3 stream reference counter gets incremented, but due to the connection being already closed Http3ExchangeImpl::close will not be invoked, even though the CF returned to the user has been correctly completed with the appropriate exception. Not calling `Http3ExchangeImpl::close` after the reference counter has been incremented prevents that reference counter from being properly decremented. This in turn causes `HttpClient::close()` to wait forever.
> 
> The fix is to double-check that the connection is still open after having added the exchange to the connection's exchange map. If the connection is still opened, we can start the exchange. Otherwise we mark it as unprocessed and close it.

src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 555:

> 553:             // only start the exchange if the connection is
> 554:             // still open
> 555:             exchange.start();

Given `isOpen()` and `exchange.start()` are not run while the lock is held, isn't there still, yet slight, a chance that the connection is closed before the `exchange.start()` invocation?

test/jdk/java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java line 1:

> 1: /*

[JDK-8372409] contains a reproducer. Have you considered converting that to a test?

[JDK-8372409]: https://bugs.openjdk.org/browse/JDK-8372409

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28494#discussion_r2564362619
PR Review Comment: https://git.openjdk.org/jdk/pull/28494#discussion_r2564362437

From vyazici at openjdk.org  Wed Nov 26 10:39:20 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 26 Nov 2025 10:39:20 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v5]
In-Reply-To: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
Message-ID: <OvgsFHHMK8elrse4NWJa1afM6CJLNQae_3y0MTfxLHY=.79381b1d-0787-47cf-a9bd-5ed262159b8d@github.com>

> Add guards against `HttpHeaders::firstValueAsLong` failures. `H3MalformedResponseTest` is overhauled ? migrated to JUnit, reinforced with exception type tests, etc. ? but not all `firstValueAsLong` changes are verified with new additional tests. `test/jdk/java/net/httpclient/` tests still do pass.

Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision:

  Introduce dangling `firstValueAsLong("content-length")` calls back

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28431/files
  - new: https://git.openjdk.org/jdk/pull/28431/files/d2d9adfe..0af344f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28431&range=03-04

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28431/head:pull/28431

PR: https://git.openjdk.org/jdk/pull/28431

From vyazici at openjdk.org  Wed Nov 26 10:39:22 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 26 Nov 2025 10:39:22 GMT
Subject: RFR: 8369595: HttpClient: HttpHeaders.firstValueAsLong failures
 should be converted to ProtocolException [v5]
In-Reply-To: <2yWFGciKBlvtLnh4ElKZo1-WWCqcvBaCZYbMs4pogOY=.1562cad3-bd33-419e-9744-abbbc89abcdc@github.com>
References: <LzyZCQ6q76WekHFtpgGx84u0C6TfOl-R_EpWMeg6Oac=.2a66207c-a933-4345-bef1-405c12ca2599@github.com>
 <zxTiQhlKNOU57ySROAoOHlilR74YL8K2t9g1yYjuHxI=.3779a20e-e069-448b-af79-35814e147e0b@github.com>
 <eZZRfvfWKRYzRT-rLe_Rc9hs2HW3KvDWI8AQLrGUpps=.d5f91104-3352-44f2-8acb-1c6e864407b8@github.com>
 <2yWFGciKBlvtLnh4ElKZo1-WWCqcvBaCZYbMs4pogOY=.1562cad3-bd33-419e-9744-abbbc89abcdc@github.com>
Message-ID: <igDoruMnAL6dja-G3aYuUDXaLIz_YeKrwpC0bxS0Mww=.7840d754-961c-4dfc-8a62-d875141d3cc3@github.com>

On Tue, 25 Nov 2025 21:01:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 1786:
>> 
>>> 1784:                    sure code up the stack handles NFE correctly. */
>>> 1785:                 responseHeaders.firstValueAsLong("content-length");
>>> 1786: 
>> 
>> We no longer check here that content-length is a number if present. Has that become unecessary?
>
> This is a fast-path to exit early if `Content-Length` is present and cannot be parsed into a `long`. AFAICT,
> 
> - The author was already either aware of the missing `Content-Length` checks, or suspecting that. Therefore he introduced this rudimentary check.
> - This concern is only relevant for `Content-Length` consumers, where we thoroughly validate the value at each use-site in this PR.

Introduced dangling `firstValueAsLong("content-length")` calls back in 0af344f1839. I will tackle this particular issue more comprehensively in a follow-up ticket.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28431#discussion_r2564456304

From dfuchs at openjdk.org  Wed Nov 26 12:35:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Nov 2025 12:35:52 GMT
Subject: RFR: 8372409:
 java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out
 during warmup
In-Reply-To: <PURaIzDZyKGfMnVCKQ8lcm9BHDJDyNtGf7IfcGM0ku8=.420b96fb-5695-4606-86f7-8c0b651c2bbd@github.com>
References: <tygDWjw3cTzV4SdBUuvbrpZhTTt4MO0ZYvphWLxrufA=.e7158864-4a13-4ac6-b404-29624aac8637@github.com>
 <PURaIzDZyKGfMnVCKQ8lcm9BHDJDyNtGf7IfcGM0ku8=.420b96fb-5695-4606-86f7-8c0b651c2bbd@github.com>
Message-ID: <QZ3kPExmIvRtz6_XVUKbQZs2ceS53yYL6uRvoy-4CD8=.f6e49855-93f2-4a5e-8e6b-f8f347e40c09@github.com>

On Wed, 26 Nov 2025 10:07:49 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> The issue here occurs when the connection gets closed just before the `Http3ExchangeImpl` gets created. In that case the h3 stream reference counter gets incremented, but due to the connection being already closed Http3ExchangeImpl::close will not be invoked, even though the CF returned to the user has been correctly completed with the appropriate exception. Not calling `Http3ExchangeImpl::close` after the reference counter has been incremented prevents that reference counter from being properly decremented. This in turn causes `HttpClient::close()` to wait forever.
>> 
>> The fix is to double-check that the connection is still open after having added the exchange to the connection's exchange map. If the connection is still opened, we can start the exchange. Otherwise we mark it as unprocessed and close it.
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 555:
> 
>> 553:             // only start the exchange if the connection is
>> 554:             // still open
>> 555:             exchange.start();
> 
> Given `isOpen()` and `exchange.start()` are not run while the lock is held, isn't there still, yet slight, a chance that the connection is closed before the `exchange.start()` invocation?

Yes - but if it happens here then the exchange will have been added to `exchanges` and therefore the Http3Connection will close it. It might not get marked as unprocessed and retried in that case - but that's a smaller issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28494#discussion_r2564832485

From vyazici at openjdk.org  Wed Nov 26 12:44:57 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Wed, 26 Nov 2025 12:44:57 GMT
Subject: RFR: 8372409:
 java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out
 during warmup
In-Reply-To: <QZ3kPExmIvRtz6_XVUKbQZs2ceS53yYL6uRvoy-4CD8=.f6e49855-93f2-4a5e-8e6b-f8f347e40c09@github.com>
References: <tygDWjw3cTzV4SdBUuvbrpZhTTt4MO0ZYvphWLxrufA=.e7158864-4a13-4ac6-b404-29624aac8637@github.com>
 <PURaIzDZyKGfMnVCKQ8lcm9BHDJDyNtGf7IfcGM0ku8=.420b96fb-5695-4606-86f7-8c0b651c2bbd@github.com>
 <QZ3kPExmIvRtz6_XVUKbQZs2ceS53yYL6uRvoy-4CD8=.f6e49855-93f2-4a5e-8e6b-f8f347e40c09@github.com>
Message-ID: <MT0he_SnydeQd20eENZt5trzP4VId-VsBCg1jcu1SV0=.6ae170cc-94ff-4805-ac9e-8011f80f6d1d@github.com>

On Wed, 26 Nov 2025 12:33:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 555:
>> 
>>> 553:             // only start the exchange if the connection is
>>> 554:             // still open
>>> 555:             exchange.start();
>> 
>> Given `isOpen()` and `exchange.start()` are not run while the lock is held, isn't there still, yet slight, a chance that the connection is closed before the `exchange.start()` invocation?
>
> Yes - but if it happens here then the exchange will have been added to `exchanges` and therefore the Http3Connection will close it. It might not get marked as unprocessed and retried in that case - but that's a smaller issue. That's what I was trying to say in the comment stating that we need to double-check if the connection is still opened *after* having added the exchange to the exchange map. It is not an issue if the exchange is closed/cancelled more than once. The first call wins :-).

`registerAndStartExchange()` is only called from `createHttp3ExchangeImpl()`, where there is the block holding the lock, just before the `registerAndStartExchange()` invocation. Would it be a good idea to obtain the `isOpen()` value there and pass it to `registerAndStartExchange()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28494#discussion_r2564862070

From djelinski1 at gmail.com  Wed Nov 26 15:06:29 2025
From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=)
Date: Wed, 26 Nov 2025 16:06:29 +0100
Subject: 8371903: HttpClient GOAWAY error handling - work status inquiry
In-Reply-To: <1C8FA4B2-E1C2-48AF-A82F-D2D11FEAE2EE@gmail.com>
References: <1C8FA4B2-E1C2-48AF-A82F-D2D11FEAE2EE@gmail.com>
Message-ID: <CAMrH03LDA3n3APtUAUPFpQhv2Tq-O8bR+Fk8KipTvMop=h_TkQ@mail.gmail.com>

Hi hyunsuEun,
Thank you for your offer. I haven't started working on the issue yet,
contributions are welcome.
Regards,
Daniel


?r., 26 lis 2025 o 03:06 ??? <ehs122100 at gmail.com> napisa?(a):
>
> Hi,
>
> I would like to contribute to JDK-8371903 (improving handling of
> HTTP/2 GOAWAY frames with error codes in HttpClient).
>
> I noticed that Daniel Jelinski is assigned to this issue. I wanted
> to check if work is currently in progress. If available, I would
> like to work on this issue and submit a PR.
>
> Please let me know if this is possible.
>
> Thanks,
> hyunsuEun

From daniel.fuchs at oracle.com  Wed Nov 26 16:21:57 2025
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 26 Nov 2025 16:21:57 +0000
Subject: 8371903: HttpClient GOAWAY error handling - work status inquiry
In-Reply-To: <CAMrH03LDA3n3APtUAUPFpQhv2Tq-O8bR+Fk8KipTvMop=h_TkQ@mail.gmail.com>
References: <1C8FA4B2-E1C2-48AF-A82F-D2D11FEAE2EE@gmail.com>
 <CAMrH03LDA3n3APtUAUPFpQhv2Tq-O8bR+Fk8KipTvMop=h_TkQ@mail.gmail.com>
Message-ID: <b2a8ef83-98eb-49fd-900d-44ba2d639257@oracle.com>

Hi,

Before working on a fix, I'd suggest working on a test
that shows the issue - checking that in flight streams are
immediately closed if the GOAWAY contains an error code.

best regards,

-- daniel

On 26/11/2025 15:06, Daniel Jeli?ski wrote:
> Hi hyunsuEun,
> Thank you for your offer. I haven't started working on the issue yet,
> contributions are welcome.
> Regards,
> Daniel
> 
> 
> ?r., 26 lis 2025 o 03:06 ??? <ehs122100 at gmail.com> napisa?(a):
>>
>> Hi,
>>
>> I would like to contribute to JDK-8371903 (improving handling of
>> HTTP/2 GOAWAY frames with error codes in HttpClient).
>>
>> I noticed that Daniel Jelinski is assigned to this issue. I wanted
>> to check if work is currently in progress. If available, I would
>> like to work on this issue and submit a PR.
>>
>> Please let me know if this is possible.
>>
>> Thanks,
>> hyunsuEun


From dfuchs at openjdk.org  Wed Nov 26 16:46:11 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Nov 2025 16:46:11 GMT
Subject: RFR: 8372409:
 java/net/httpclient/http3/H3MultipleConnectionsToSameHost.java timed out
 during warmup
In-Reply-To: <MT0he_SnydeQd20eENZt5trzP4VId-VsBCg1jcu1SV0=.6ae170cc-94ff-4805-ac9e-8011f80f6d1d@github.com>
References: <tygDWjw3cTzV4SdBUuvbrpZhTTt4MO0ZYvphWLxrufA=.e7158864-4a13-4ac6-b404-29624aac8637@github.com>
 <PURaIzDZyKGfMnVCKQ8lcm9BHDJDyNtGf7IfcGM0ku8=.420b96fb-5695-4606-86f7-8c0b651c2bbd@github.com>
 <QZ3kPExmIvRtz6_XVUKbQZs2ceS53yYL6uRvoy-4CD8=.f6e49855-93f2-4a5e-8e6b-f8f347e40c09@github.com>
 <MT0he_SnydeQd20eENZt5trzP4VId-VsBCg1jcu1SV0=.6ae170cc-94ff-4805-ac9e-8011f80f6d1d@github.com>
Message-ID: <ewL0nn9DFjSU5Q-DqcLQBtvgsPzPBo73x5IC05R79lQ=.4c597a9d-2245-47f0-86de-fdc7ee8ecda4@github.com>

On Wed, 26 Nov 2025 12:42:34 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Yes - but if it happens here then the exchange will have been added to `exchanges` and therefore the Http3Connection will close it. It might not get marked as unprocessed and retried in that case - but that's a smaller issue. That's what I was trying to say in the comment stating that we need to double-check if the connection is still opened *after* having added the exchange to the exchange map. It is not an issue if the exchange is closed/cancelled more than once. The first call wins :-).
>
> `registerAndStartExchange()` is only called from `createHttp3ExchangeImpl()`, where there is the block holding the lock, just before the `registerAndStartExchange()` invocation. Would it be a good idea to obtain the `isOpen()` value there and pass it to `registerAndStartExchange()`?

No - as I said we need to do the check after updating the `exchanges` map - so specifically after this line:

exchanges.put(streamId, exchange);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28494#discussion_r2565712867

From dfuchs at openjdk.org  Wed Nov 26 17:34:32 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Nov 2025 17:34:32 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v8]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <-HvV4rlXNr0E_3PrsX---QIuAA6T6ERQAx9NgBeeN2w=.8c56986d-18e5-4fa0-bc39-35aa28c97dff@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into ConnectionCloseLock-8372198
 - test updates: add diagnosis, configure the backlog to be at least the number of concurrent requests
 - More test updates
 - test updates
 - Review feedback: added a test
 - Merge branch 'master' into ConnectionCloseLock-8372198
 - Merge branch 'master' into ConnectionCloseLock-8372198
 - Merge master
 - 8372198: Avoid closing PlainHttpConnection while holding a lock
 - Merge branch 'master' into SelectorManagerVT-8372159
 - ... and 4 more: https://git.openjdk.org/jdk/compare/c028369d...3530d078

-------------

Changes: https://git.openjdk.org/jdk/pull/28430/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=07
  Stats: 431 lines in 4 files changed: 406 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Wed Nov 26 17:46:40 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Nov 2025 17:46:40 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v9]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <wmRVK6jZkmIwHo-eRP4EZrgQNw0u_0Be_fzVjhABZz8=.7e1c2cb3-5ed3-4bcc-8648-606fba75cbbc@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  test update: remove left over from debug session

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28430/files
  - new: https://git.openjdk.org/jdk/pull/28430/files/3530d078..04469dee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Wed Nov 26 17:46:44 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 26 Nov 2025 17:46:44 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <vAtwnG2DrZD__DUDwR04EesuHJ4l86RzGEDcfmiO_Xo=.bc15a62c-d108-4c51-828f-8198cfa8317d@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
 <vAtwnG2DrZD__DUDwR04EesuHJ4l86RzGEDcfmiO_Xo=.bc15a62c-d108-4c51-828f-8198cfa8317d@github.com>
Message-ID: <FwNHTJnNMaWBj1TS-wLzjausRl0NwA5rbvUbwYbvxXE=.033d1415-8989-4ed5-a59e-61ff1f638c10@github.com>

On Tue, 25 Nov 2025 10:11:49 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Merge branch 'master' into ConnectionCloseLock-8372198
>>  - Merge master
>>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>>  - Merge branch 'master' into SelectorManagerVT-8372159
>>  - Copyright years
>>  - Review feedback on test
>>  - Revert changes to SelectorManager::shutdown
>>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread
>
> I see the `noreg-hard` label. An approach that you might consider exploring:
> 
> 1. Configure `jdk.httpclient.connectionPoolSize` to something really low (e.g., 1) to force `returnToPool()` to close excessive connections
> 2. Configure an `HttpTestServer` that blocks all `HttpTestExchange::sendResponseHeaders` behind a latch
> 3. Fire 100 `sendAsync().thenCompose(responseFutures::add)`, where `responseFutures` is an unbounded `BlockingQueue<HttpResponse>`
> 4. Release the `sendResponseHeaders` latch
> 5. Verify the success of the very first response, i.e., `responseFutures.enqueue()`
> 6. Shutdown the client without waiting for the rest of the responses to arrive
> 7. Wrap the test method in a `@RepeatedTest(50)`

@vy - the test you requested is ready to be reviewed. It seems stable now even on windows. Let me know what you think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28430#issuecomment-3582522966

From jpai at openjdk.org  Thu Nov 27 05:18:01 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 05:18:01 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when HTTP/3
 is configured with a higher idle timeout
Message-ID: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>

Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?

QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).

In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.

Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.

The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would generate the necessary traffic to keep the connection alive (for example if the response processing is taking a long time on the server side, then the server is expected to generate a PING to keep that connection active).

A new jtreg test has been introduced to verify that a HTTP/3 connection with a higher idle timeout than the QUIC idle timeout, doesn't cause the connection to be idle terminated by QUIC.

-------------

Commit messages:
 - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

Changes: https://git.openjdk.org/jdk/pull/28522/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371802
  Stats: 628 lines in 8 files changed: 529 ins; 50 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522

From jpai at openjdk.org  Thu Nov 27 05:27:35 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 05:27:35 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v2]
In-Reply-To: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
Message-ID: <hD8pVnj8XZ5s0V7rHVaOwVLu4CYhulxnqhHJtWE68n8=.3c5efba9-9f17-44cc-95ba-e4bd01b3b806@github.com>

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - fix unintended check
 - merge latest from master branch
 - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28522/files
  - new: https://git.openjdk.org/jdk/pull/28522/files/47014937..b5208f65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=00-01

  Stats: 1625 lines in 63 files changed: 829 ins; 409 del; 387 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522

From jpai at openjdk.org  Thu Nov 27 07:08:26 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 07:08:26 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
Message-ID: <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  fix duration overflow issue with Duration.toMillis()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28522/files
  - new: https://git.openjdk.org/jdk/pull/28522/files/b5208f65..b3b73048

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=01-02

  Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522

From djelinski at openjdk.org  Thu Nov 27 09:30:01 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Nov 2025 09:30:01 GMT
Subject: RFR: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support [v2]
In-Reply-To: <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
 <jfKR-D1jl0Imw1YFVZmDAjePZGNxeUIxTND0r7G-4vc=.527609e3-ae3c-42be-8653-5653ff95ee3e@github.com>
Message-ID: <w3yib-orxFN9UyioIOpE5t7_fcrb4d8jrPcp9qAPqJA=.b5eae557-a273-4d91-a151-8fd37a63650a@github.com>

On Tue, 25 Nov 2025 10:46:34 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
>> 
>> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
>> 
>> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Cleanup HttpClientImpl ctor
>  - Rename setParams

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28480#issuecomment-3584909472

From djelinski at openjdk.org  Thu Nov 27 09:30:02 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Nov 2025 09:30:02 GMT
Subject: Integrated: 8371887: HttpClient: SSLParameters with no protocols
 configured disable HTTP2+ support
In-Reply-To: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
References: <gtPZKR3kUfXrbBBEyE1xDybtvR3zKn-UQAlTjYOf4Io=.013a196d-a1b2-4d83-9a7a-3f2fa6c08e69@github.com>
Message-ID: <l8u7AUiPcjYF0TWBIPA83_vjcWrzyQUgnLbxqjRoGS8=.6af38d3b-e556-42cc-985b-7f8cb61067a9@github.com>

On Mon, 24 Nov 2025 17:52:54 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> When checking for supported TLS versions, use SSLContext default parameters if the provided SSLParameters have no protocols configured.
> 
> This fixes an issue where using SSLParameters with no protocols disabled the use of HTTP2 and HTTP3, even when these protocols were supported and enabled in the SSLContext.
> 
> Modified the existing tests to additionally cover the case of empty SSLParameters. All tests continue to pass.

This pull request has now been integrated.

Changeset: 1f417e77
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f417e77615c570ca3002b13a1398b647133ad67
Stats:     120 lines in 7 files changed: 68 ins; 39 del; 13 mod

8371887: HttpClient: SSLParameters with no protocols configured disable HTTP2+ support

Reviewed-by: jpai, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28480

From dfuchs at openjdk.org  Thu Nov 27 09:50:46 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 09:50:46 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
Message-ID: <y-R-eNFZHBBbMMmioELEx-BBXfwXUuXzj_WXJxkWd7s=.58051ee7-b795-438b-806c-f8984fbd4074@github.com>

On Thu, 27 Nov 2025 07:08:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
>> 
>> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
>> 
>> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
>> 
>> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
>> 
>> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those reques...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix duration overflow issue with Duration.toMillis()

src/java.net.http/share/classes/jdk/internal/net/http/quic/IdleTimeoutManager.java line 683:

> 681:                 if (idleTerminationAt <= nextPingCheck) {
> 682:                     return true;
> 683:                 }

The math doesn't look good here since we're dealing with nanos. We should allow the overflow when adding the delay and use sustraction rather than <= for the final check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567833669

From dfuchs at openjdk.org  Thu Nov 27 09:56:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 09:56:48 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <y-R-eNFZHBBbMMmioELEx-BBXfwXUuXzj_WXJxkWd7s=.58051ee7-b795-438b-806c-f8984fbd4074@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
 <y-R-eNFZHBBbMMmioELEx-BBXfwXUuXzj_WXJxkWd7s=.58051ee7-b795-438b-806c-f8984fbd4074@github.com>
Message-ID: <Bxz133ExSI8dBFaioVDIYo7Nqb0T08jYvnB4gYaR83M=.a7630853-6597-43f8-b705-02558670b170@github.com>

On Thu, 27 Nov 2025 09:48:27 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix duration overflow issue with Duration.toMillis()
>
> src/java.net.http/share/classes/jdk/internal/net/http/quic/IdleTimeoutManager.java line 683:
> 
>> 681:                 if (idleTerminationAt <= nextPingCheck) {
>> 682:                     return true;
>> 683:                 }
> 
> The math doesn't look good here since we're dealing with nanos. We should allow the overflow when adding the delay and use sustraction rather than <= for the final check.

final long idleTerminationAt = lastPktAt + this.idleTimeoutNanos;
final long nextPingCheck = now + his.pingFrequencyNanos;
if (idleTerminationAt - nextPingCheck <= 0) return true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567850724

From dfuchs at openjdk.org  Thu Nov 27 10:09:55 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 10:09:55 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
Message-ID: <vxOEPmK-4QXnlKnY9RhHUmuslwa2p48CvgnOVR6IbDQ=.d4703d77-6749-4969-ae10-3cf7e55cbb66@github.com>

On Thu, 27 Nov 2025 07:08:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
>> 
>> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
>> 
>> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
>> 
>> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
>> 
>> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those reques...
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix duration overflow issue with Duration.toMillis()

Changes requested by dfuchs (Reviewer).

src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 138:

> 136:     // true if this connection has been placed in the HTTP/3 connection pool of the HttpClient.
> 137:     // false otherwise.
> 138:     private volatile boolean presentInConnPool;

In theory a connection that is not in the pool should be marked as `finalStream` ;

src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 917:

> 915:             // in the pool (thus idle), then we instruct QUIC to generate traffic on the
> 916:             // QUIC connection to prevent it from being idle terminated.
> 917:             final boolean generateTraffic = this.presentInConnPool

I wonder if `this.presentInConnPool` can be replaced with `!this.finalStream`

test/jdk/java/net/Foo.java line 1:

> 1: import java.net.InetSocketAddress;

Seems that this file was added by mistake

-------------

PR Review: https://git.openjdk.org/jdk/pull/28522#pullrequestreview-3514375028
PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567867831
PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567882968
PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567892716

From jpai at openjdk.org  Thu Nov 27 10:15:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 10:15:27 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v4]
In-Reply-To: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
Message-ID: <ioznVgVPUAPFmeu8fbl6zA2zyCyGFm2YebwQT6Z4bJg=.f4a0f010-450a-4736-8e59-dd3e185a990f@github.com>

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  remove unwanted file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28522/files
  - new: https://git.openjdk.org/jdk/pull/28522/files/b3b73048..0e55e4a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=02-03

  Stats: 29 lines in 1 file changed: 0 ins; 29 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522

From jpai at openjdk.org  Thu Nov 27 10:15:28 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 10:15:28 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <vxOEPmK-4QXnlKnY9RhHUmuslwa2p48CvgnOVR6IbDQ=.d4703d77-6749-4969-ae10-3cf7e55cbb66@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
 <vxOEPmK-4QXnlKnY9RhHUmuslwa2p48CvgnOVR6IbDQ=.d4703d77-6749-4969-ae10-3cf7e55cbb66@github.com>
Message-ID: <-dnLCZfgjpAvdxpOj8X_q6wqkk4xl9mmoq3MWCSzIJQ=.ae1e7a81-11a7-477c-8446-bef62727f89c@github.com>

On Thu, 27 Nov 2025 10:06:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix duration overflow issue with Duration.toMillis()
>
> test/jdk/java/net/Foo.java line 1:
> 
>> 1: import java.net.InetSocketAddress;
> 
> Seems that this file was added by mistake

Indeed. I was experimenting with some unrelated issue and it looks like I accidentally git added this file. I've updated the PR to remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2567906057

From vyazici at openjdk.org  Thu Nov 27 12:23:56 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 27 Nov 2025 12:23:56 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v9]
In-Reply-To: <wmRVK6jZkmIwHo-eRP4EZrgQNw0u_0Be_fzVjhABZz8=.7e1c2cb3-5ed3-4bcc-8648-606fba75cbbc@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <wmRVK6jZkmIwHo-eRP4EZrgQNw0u_0Be_fzVjhABZz8=.7e1c2cb3-5ed3-4bcc-8648-606fba75cbbc@github.com>
Message-ID: <e_7rAjJKZ5uY3PObvAlzIFV7s1HaEhzgnRKDJYFwJ68=.a76262f9-17ba-46cf-a490-c453c4420b10@github.com>

On Wed, 26 Nov 2025 17:46:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test update: remove left over from debug session

@dfuch, thanks so much for the test. It will certainly help with unintentionally introducing a similar unexpected behavior in the future.

I've dropped some minor remarks and questions, but I see no blockers ? LGTM. You can decide to address my comments as you wish.

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 124:

> 122:             response.acquire();
> 123:             return true;
> 124:         } catch (InterruptedException x) {

_Nit:_ While it might not make much of difference in this particular case, I think it is always a good practice to not discard `InterruptedException` ? this has recently been [discussed on core-libs-dev].

Suggestion:

        } catch (InterruptedException x) {
            Thread.currentThread().interrupt();  // Restore the interrupt


[discussed on core-libs-dev]: https://mail.openjdk.org/pipermail/core-libs-dev/2025-November/154551.html

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 131:

> 129: 
> 130:     @BeforeEach
> 131:     synchronized void beforeTest() throws Exception {

Do we really need `synchronized` here?

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 138:

> 136:         if (sslContext == null) {
> 137:             throw new AssertionError("Unexpected null sslContext");
> 138:         }

_Nit:_ `sslContext` can be a class (i.e., `static`) field, and reused.

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 143:

> 141: 
> 142:         // On windows, sending 100 concurrent requests may
> 143:         // fail is the server's connection backlog is less than 100.

Suggestion:

        // On Windows, sending 100 concurrent requests may
        // fail if the server's connection backlog is less than 100.

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 146:

> 144:         // The default backlog is 50. Just make sure the backlog is
> 145:         // big enough.
> 146:         int backlog = MANY > 50 ? MANY : 50;

_Nit:_ A simpler alternative:

Suggestion:

        int backlog = Math.max(MANY, 50);

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 159:

> 157:                 exchange.sendResponseHeaders(500, 0);
> 158:             }
> 159:         }, "/PlainConnectionLockTest/");

Both servers have identical server handlers. You can consider extracting it into a variable, and reusing it both in `https1Server::addHandler` and `http1Server::addHandler`.

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 165:

> 163: 
> 164:         // create a plain http server for HTTP/1.1
> 165:         var wrappedHttp1Server = HttpServer.create(new InetSocketAddress(InetAddress.getLoopbackAddress(), 0), backlog);

Suggestion:

        var wrappedHttp1Server = HttpServer.create(new InetSocketAddress(loopback, 0), backlog);

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 214:

> 212:         } catch (Throwable t) {
> 213:             t.printStackTrace(System.out);
> 214:             throw t;

I see a longing for TestNG, where stack traces were dumped into stdout, and stderr is populated with more verbose logging. ?

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 272:

> 270:     }
> 271: 
> 272:     private synchronized void sendManyRequests(final String requestURI, final int many, boolean shutdown) throws Exception {

Is `synchronized` necessary here?

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 272:

> 270:     }
> 271: 
> 272:     private synchronized void sendManyRequests(final String requestURI, final int many, boolean shutdown) throws Exception {

When `shutdown = false`, we expect all request-response exchange to succeed with 200. In the context of the tested behaviour, which case does `shutdown = false` stress?

test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 350:

> 348:             // wait for all responses
> 349:             System.out.printf("%sWaiting for all %s responses to complete%n", now(), many);
> 350:             CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).exceptionally(t -> null).join();

Is `exceptionally(t -> null)` a refactoring leftover?

-------------

Marked as reviewed by vyazici (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28430#pullrequestreview-3514427710
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2567926507
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2567914626
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568061462
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2567928870
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568028255
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568051609
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568045225
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568268591
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568275803
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568394233
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568377890

From vyazici at openjdk.org  Thu Nov 27 12:36:54 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 27 Nov 2025 12:36:54 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v4]
In-Reply-To: <FwNHTJnNMaWBj1TS-wLzjausRl0NwA5rbvUbwYbvxXE=.033d1415-8989-4ed5-a59e-61ff1f638c10@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <BFQVVbLbVBMXyQT9RDVZjqdtEXVj23RJHvq2vhRiZ8U=.f9983f4c-d74f-446f-b96b-cb8c2dbede53@github.com>
 <vAtwnG2DrZD__DUDwR04EesuHJ4l86RzGEDcfmiO_Xo=.bc15a62c-d108-4c51-828f-8198cfa8317d@github.com>
 <FwNHTJnNMaWBj1TS-wLzjausRl0NwA5rbvUbwYbvxXE=.033d1415-8989-4ed5-a59e-61ff1f638c10@github.com>
Message-ID: <YH3-4SwQiVRn-u6unHLp89ml-DuzyNo3uUVNWFFknM0=.860f72c4-66c9-4c7e-9c99-ca6f1068600d@github.com>

On Wed, 26 Nov 2025 17:43:41 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I see the `noreg-hard` label. An approach that you might consider exploring:
>> 
>> 1. Configure `jdk.httpclient.connectionPoolSize` to something really low (e.g., 1) to force `returnToPool()` to close excessive connections
>> 2. Configure an `HttpTestServer` that blocks all `HttpTestExchange::sendResponseHeaders` behind a latch
>> 3. Fire 100 `sendAsync().thenCompose(responseFutures::add)`, where `responseFutures` is an unbounded `BlockingQueue<HttpResponse>`
>> 4. Release the `sendResponseHeaders` latch
>> 5. Verify the success of the very first response, i.e., `responseFutures.enqueue()`
>> 6. Shutdown the client without waiting for the rest of the responses to arrive
>> 7. Wrap the test method in a `@RepeatedTest(50)`
>
> @vy - the test you requested is ready to be reviewed. It seems stable now even on windows. Let me know what you think.

@dfuch, I revert your changes and run the test, and it passes. I doubt if this is what you intended. Shouldn't it be failing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28430#issuecomment-3585632873

From dfuchs at openjdk.org  Thu Nov 27 12:46:34 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 12:46:34 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v10]
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:

 - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
 - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
   
   Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28430/files
  - new: https://git.openjdk.org/jdk/pull/28430/files/04469dee..dc6a1373

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28430&range=08-09

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28430.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28430/head:pull/28430

PR: https://git.openjdk.org/jdk/pull/28430

From dfuchs at openjdk.org  Thu Nov 27 12:46:36 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 12:46:36 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v9]
In-Reply-To: <e_7rAjJKZ5uY3PObvAlzIFV7s1HaEhzgnRKDJYFwJ68=.a76262f9-17ba-46cf-a490-c453c4420b10@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <wmRVK6jZkmIwHo-eRP4EZrgQNw0u_0Be_fzVjhABZz8=.7e1c2cb3-5ed3-4bcc-8648-606fba75cbbc@github.com>
 <e_7rAjJKZ5uY3PObvAlzIFV7s1HaEhzgnRKDJYFwJ68=.a76262f9-17ba-46cf-a490-c453c4420b10@github.com>
Message-ID: <1Nb-bfpMx8g_dlH8ZRQ9-encPxpRuOWh1vzSAff0izk=.27cfebef-2fa5-483c-8fd7-b241e592895b@github.com>

On Thu, 27 Nov 2025 10:13:02 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test update: remove left over from debug session
>
> test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 131:
> 
>> 129: 
>> 130:     @BeforeEach
>> 131:     synchronized void beforeTest() throws Exception {
> 
> Do we really need `synchronized` here?

Probably not - as Junit should take care that methods don't run concurrently. But on windows my test got wedged for reasons I could not explain so I started doubting everything. In particular - we don't want one test method (or server) reusing the semaphore that had been created for the other method. That's also why the server handler captures those semaphore instead of reading the field. The problem on windows has been resolved now - it was caused by insufficient backlog, but I'll keep the synchronize, it should not hurt.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568483247

From dfuchs at openjdk.org  Thu Nov 27 12:58:00 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 12:58:00 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v10]
In-Reply-To: <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
Message-ID: <3Aj4zXWUY2-vnpcCODLDL195et_wHQzz84wRnWDiisQ=.08c918e0-7710-4a66-9b66-d655ee7d45c6@github.com>

On Thu, 27 Nov 2025 12:46:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

The issue being fixed is a race condition so you would have to be very lucky to make it fail. It might require adding Thread.sleep in the product code and I haven't investigated that far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28430#issuecomment-3585714126

From dfuchs at openjdk.org  Thu Nov 27 12:58:05 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 12:58:05 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v9]
In-Reply-To: <e_7rAjJKZ5uY3PObvAlzIFV7s1HaEhzgnRKDJYFwJ68=.a76262f9-17ba-46cf-a490-c453c4420b10@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <wmRVK6jZkmIwHo-eRP4EZrgQNw0u_0Be_fzVjhABZz8=.7e1c2cb3-5ed3-4bcc-8648-606fba75cbbc@github.com>
 <e_7rAjJKZ5uY3PObvAlzIFV7s1HaEhzgnRKDJYFwJ68=.a76262f9-17ba-46cf-a490-c453c4420b10@github.com>
Message-ID: <foYqdk3974hZsXwrlct81eKEhyBjdDC9a3fMZUtJZ80=.86204f46-252c-45f2-a79e-7e59b9a911f6@github.com>

On Thu, 27 Nov 2025 11:46:35 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test update: remove left over from debug session
>
> test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 214:
> 
>> 212:         } catch (Throwable t) {
>> 213:             t.printStackTrace(System.out);
>> 214:             throw t;
> 
> I see a longing for TestNG, where stack traces were dumped into stdout, and stderr is populated with more verbose logging. ?

For some reason those stack traces did not show up. Now I believe it was due to not calling `client.shutDownNow()` (a bug in a previous version of the test) in the loop that tries to acquire the permits, when an `AssertionError` is thrown there. In that case since the client was not shutdown the try-with-resource would wait on request to complete which would not happen since the semaphore the server was waiting on was not released, and the requests whose response was waiting on this semaphore where not cancelled. Another reason why I doubted everything ;-). Printing those exceptions to system.out avoid having to look for them in System.err where they could be lost in the noise of server side exceptions throwns when requests are cancelled by `client.shutdownNow`

> test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 272:
> 
>> 270:     }
>> 271: 
>> 272:     private synchronized void sendManyRequests(final String requestURI, final int many, boolean shutdown) throws Exception {
> 
> Is `synchronized` necessary here?

See reply above

> test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 272:
> 
>> 270:     }
>> 271: 
>> 272:     private synchronized void sendManyRequests(final String requestURI, final int many, boolean shutdown) throws Exception {
> 
> When `shutdown = false`, we expect all request-response exchange to succeed with 200. In the context of the tested behaviour, which case does `shutdown = false` stress?

close while return to pool after succeful 200

> test/jdk/java/net/httpclient/PlainConnectionLockTest.java line 350:
> 
>> 348:             // wait for all responses
>> 349:             System.out.printf("%sWaiting for all %s responses to complete%n", now(), many);
>> 350:             CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).exceptionally(t -> null).join();
> 
> Is `exceptionally(t -> null)` a refactoring leftover?

No - we  don't want to fail here when shutdown==true, we want to check all the cfs first, we will fail later while checking them if necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568526083
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568527599
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568540656
PR Review Comment: https://git.openjdk.org/jdk/pull/28430#discussion_r2568535133

From vyazici at openjdk.org  Thu Nov 27 13:10:07 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 27 Nov 2025 13:10:07 GMT
Subject: RFR: 8372147: ConnectionFlowControlTest should use
 HttpResponse.connectionLabel()
Message-ID: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>

Use `HttpResponse::connectionLabel` instead of `Http2TestExchange::connectionKey` to identify the connection request-response exchange is performed on, for the latter can accidentally return the same identifier again, e.g., if a closed connection is immediately reused.

-------------

Commit messages:
 - Use `HttpResponse::connectionLabel` in `ConnectionFlowControlTest`

Changes: https://git.openjdk.org/jdk/pull/28534/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28534&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372147
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28534.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28534/head:pull/28534

PR: https://git.openjdk.org/jdk/pull/28534

From vyazici at openjdk.org  Thu Nov 27 13:10:09 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Thu, 27 Nov 2025 13:10:09 GMT
Subject: RFR: 8372147: ConnectionFlowControlTest should use
 HttpResponse.connectionLabel()
In-Reply-To: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
References: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
Message-ID: <sT0phvCdyMmCOm-SqlwsLQ0j3zpSSsyvBIwzRBSpKbk=.318fb820-8c9d-494e-96c8-dac357c08273@github.com>

On Thu, 27 Nov 2025 13:03:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Use `HttpResponse::connectionLabel` instead of `Http2TestExchange::connectionKey` to identify the connection request-response exchange is performed on, for the latter can accidentally return the same identifier again, e.g., if a closed connection is immediately reused.

test/jdk/java/net/httpclient/http2/ConnectionFlowControlTest.java line 1:

> 1: /*

`@bug` is intentionally not extended with [JDK-8372147], since the test does not verify a problem reported in that ticket.

[JDK-8372147]: https://bugs.openjdk.org/browse/JDK-8372147

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28534#discussion_r2568601469

From dfuchs at openjdk.org  Thu Nov 27 13:19:48 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 13:19:48 GMT
Subject: RFR: 8372147: ConnectionFlowControlTest should use
 HttpResponse.connectionLabel()
In-Reply-To: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
References: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
Message-ID: <ETl15WtvJXNkxfdJdsG7h_nQOdAatZ9silYpdFg7dQ8=.bf89c001-901d-4b85-8616-3e8d59cfc17b@github.com>

On Thu, 27 Nov 2025 13:03:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Use `HttpResponse::connectionLabel` instead of `Http2TestExchange::connectionKey` to identify the connection request-response exchange is performed on, for the latter can accidentally return the same identifier again, e.g., if a closed connection is immediately reused.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28534#pullrequestreview-3515314978

From dfuchs at openjdk.org  Thu Nov 27 16:51:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 16:51:53 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v2]
In-Reply-To: <GfSPXhr3CkhTQSM_417XuJg7jOD6CiencqLFhXHyh2k=.9845eb21-1a9b-48c3-af44-5b3f747b8c41@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <GfSPXhr3CkhTQSM_417XuJg7jOD6CiencqLFhXHyh2k=.9845eb21-1a9b-48c3-af44-5b3f747b8c41@github.com>
Message-ID: <DzK2yn3aTTdsWQLtvzF7-WZKwUNfumpUbWYmxdWIRok=.b39b0a3a-f311-411a-ac41-6adbc03beaa7@github.com>

On Mon, 24 Nov 2025 11:46:00 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - 8372198: Avoid closing PlainHttpConnection while holding a lock
>>  - Merge branch 'master' into SelectorManagerVT-8372159
>>  - Copyright years
>>  - Review feedback on test
>>  - Revert changes to SelectorManager::shutdown
>>  - 8372159: HttpClient SelectorManager thread could be a VirtualThread
>
> Marked as reviewed by djelinski (Reviewer).

May I have a final review @djelinski @jaikiran ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28430#issuecomment-3586768154

From jpai at openjdk.org  Thu Nov 27 17:16:49 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 17:16:49 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v10]
In-Reply-To: <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
Message-ID: <CzBwOFbkFw_IwJuhMqXJywm6diV3soBREqKLbHlj2FU=.d7799de6-c3d8-4283-b2ce-7bb140e86c1b@github.com>

On Thu, 27 Nov 2025 12:46:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

I haven't paid close attention to the test, but the source changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28430#pullrequestreview-3516441878

From jpai at openjdk.org  Thu Nov 27 17:19:50 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 17:19:50 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v10]
In-Reply-To: <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
Message-ID: <UdOvqdL3aWxWNJbdmYPwBQ4MJGuX4yyU4bkaHSpz280=.6f9bde2b-f623-4937-95c7-0fa01435bd2b@github.com>

On Thu, 27 Nov 2025 12:46:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

I haven't paid close attention to the test, but the source changes look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28430#pullrequestreview-3516450102

From djelinski at openjdk.org  Thu Nov 27 17:44:50 2025
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 27 Nov 2025 17:44:50 GMT
Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a
 lock [v10]
In-Reply-To: <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
 <ENt8ohGSzNTTkGHZ5Y4TqFFXKlmDIDhGgEyffLkbUIs=.9a471a52-9ce7-4d27-bd40-207d9a8e68d1@github.com>
Message-ID: <u9bTCxRbHI-lpVCC1rpOCL5whPspfCLaTg3UNHTNZn8=.10408091-777a-4ff8-86b2-7db76de79466@github.com>

On Thu, 27 Nov 2025 12:46:34 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
>> 
>> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
>> 
>> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
>> 
>> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
>> 
>> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421
>
> Daniel Fuchs has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>
>  - Update test/jdk/java/net/httpclient/PlainConnectionLockTest.java
>    
>    Co-authored-by: Volkan Yaz?c? <volkan.yazici at oracle.com>

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28430#pullrequestreview-3516516428

From dfuchs at openjdk.org  Thu Nov 27 17:58:59 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 27 Nov 2025 17:58:59 GMT
Subject: Integrated: 8372198: Avoid closing PlainHttpConnection while holding a
 lock
In-Reply-To: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
References: <iam6pIzJtCHS0uinUc2I6G4dQmm0uh-vb0Ba_XFsDdE=.3e9f9c16-ac4e-4c8f-863d-c62e70cef687@github.com>
Message-ID: <rfOLvspYrwiYnUPb7Rd4HN3SJk30EXfyLAhY1_rjxg8=.68a18cda-7a65-42a6-8610-5dee780ed26c@github.com>

On Thu, 20 Nov 2025 13:10:53 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> An experimental change to SelectorManager::shutdown unveiled a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool.
> 
> The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool.
> 
> This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test.
> 
> To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock.
> 
> This PR was recreated due to a bad merge pushed to https://github.com/openjdk/jdk/pull/28421

This pull request has now been integrated.

Changeset: 8a0672c8
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a0672c819e09a16c30fbdf58dc2b81f50958da4
Stats:     431 lines in 4 files changed: 406 ins; 9 del; 16 mod

8372198: Avoid closing PlainHttpConnection while holding a lock

Reviewed-by: djelinski, jpai, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/28430

From jpai at openjdk.org  Fri Nov 28 06:47:54 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 06:47:54 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v5]
In-Reply-To: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
Message-ID: <voMF60nbpNBvc6rjca1ILe4CXKOgU0V7ugJBk6stNtI=.0f81a915-94c9-4105-bfdd-4e63e76cbf8c@github.com>

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Daniel's suggestion - remove Math.addExact() calls
 - merge latest from master branch
 - remove unwanted file
 - fix duration overflow issue with Duration.toMillis()
 - fix unintended check
 - merge latest from master branch
 - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28522/files
  - new: https://git.openjdk.org/jdk/pull/28522/files/0e55e4a6..89f3854e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=03-04

  Stats: 1229 lines in 60 files changed: 744 ins; 302 del; 183 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522

From jpai at openjdk.org  Fri Nov 28 11:46:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 11:46:29 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v6]
In-Reply-To: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
Message-ID: <AuY0UhgGHQweAwCDUQNd0BvXmHyHBhDp2cBg6n2G9o0=.9e9d24be-f03b-4c59-a0e2-eba2ebf12859@github.com>

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - merge latest from master branch
 - don't explicitly generate QUIC traffic for connection marked as finalStream
 - Daniel's suggestion - remove Math.addExact() calls
 - merge latest from master branch
 - remove unwanted file
 - fix duration overflow issue with Duration.toMillis()
 - fix unintended check
 - merge latest from master branch
 - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28522/files
  - new: https://git.openjdk.org/jdk/pull/28522/files/89f3854e..323a476e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28522&range=04-05

  Stats: 518 lines in 99 files changed: 409 ins; 1 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/28522.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28522/head:pull/28522

PR: https://git.openjdk.org/jdk/pull/28522

From jpai at openjdk.org  Fri Nov 28 11:46:29 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 11:46:29 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <vxOEPmK-4QXnlKnY9RhHUmuslwa2p48CvgnOVR6IbDQ=.d4703d77-6749-4969-ae10-3cf7e55cbb66@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
 <vxOEPmK-4QXnlKnY9RhHUmuslwa2p48CvgnOVR6IbDQ=.d4703d77-6749-4969-ae10-3cf7e55cbb66@github.com>
Message-ID: <QSp2jotT3nfRJycijWytnxfjL-6CWRCuhGFPc398xP8=.65ce9b48-bfe5-49bc-baf3-d9cca32b97db@github.com>

On Thu, 27 Nov 2025 10:03:29 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix duration overflow issue with Duration.toMillis()
>
> src/java.net.http/share/classes/jdk/internal/net/http/Http3Connection.java line 917:
> 
>> 915:             // in the pool (thus idle), then we instruct QUIC to generate traffic on the
>> 916:             // QUIC connection to prevent it from being idle terminated.
>> 917:             final boolean generateTraffic = this.presentInConnPool
> 
> I wonder if `this.presentInConnPool` can be replaced with `!this.finalStream`

Me and Daniel discussed about this and we decided to include a `!finalStream` check too. The PR has been updated with this change. The test continues to pass and I've triggered a CI run with these latest updates.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2571397973

From jpai at openjdk.org  Fri Nov 28 11:46:30 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 11:46:30 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v3]
In-Reply-To: <Bxz133ExSI8dBFaioVDIYo7Nqb0T08jYvnB4gYaR83M=.a7630853-6597-43f8-b705-02558670b170@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <Pvlqbi_YGxVyJrzX6a-uw0nFruZQKxvO9MLhHDrbgDU=.b85466b9-2eac-421a-bcbf-f92ae8c0b53c@github.com>
 <y-R-eNFZHBBbMMmioELEx-BBXfwXUuXzj_WXJxkWd7s=.58051ee7-b795-438b-806c-f8984fbd4074@github.com>
 <Bxz133ExSI8dBFaioVDIYo7Nqb0T08jYvnB4gYaR83M=.a7630853-6597-43f8-b705-02558670b170@github.com>
Message-ID: <NHPWI7GO1pnIPPJWTbgUSmejAL23s8sujHjWfn_oYG8=.785c9ce5-9be5-46f4-8f64-247f6be47adf@github.com>

On Thu, 27 Nov 2025 09:53:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/quic/IdleTimeoutManager.java line 683:
>> 
>>> 681:                 if (idleTerminationAt <= nextPingCheck) {
>>> 682:                     return true;
>>> 683:                 }
>> 
>> The math doesn't look good here since we're dealing with nanos. We should allow the overflow when adding the delay and use sustraction rather than <= for the final check.
>
> final long idleTerminationAt = lastPktAt + this.idleTimeoutNanos;
> final long nextPingCheck = now + his.pingFrequencyNanos;
> if (idleTerminationAt - nextPingCheck <= 0) return true;

Done, I've updated the PR with this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28522#discussion_r2571396137

From vyazici at openjdk.org  Fri Nov 28 12:07:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 28 Nov 2025 12:07:59 GMT
Subject: RFR: 8372147: ConnectionFlowControlTest should use
 HttpResponse.connectionLabel()
In-Reply-To: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
References: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
Message-ID: <3n1mtDQU7LLilCIbf3w3V3zwDpHXAhZ5N69S2b9ABfw=.d5ac1d5d-9197-4466-8585-8fdd75c2da1e@github.com>

On Thu, 27 Nov 2025 13:03:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Use `HttpResponse::connectionLabel` instead of `Http2TestExchange::connectionKey` to identify the connection request-response exchange is performed on, for the latter can accidentally return the same identifier again, e.g., if a closed connection is immediately reused.

Run the test 100 times on several platforms ? results are green.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28534#issuecomment-3589065660

From vyazici at openjdk.org  Fri Nov 28 12:07:59 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Fri, 28 Nov 2025 12:07:59 GMT
Subject: Integrated: 8372147: ConnectionFlowControlTest should use
 HttpResponse.connectionLabel()
In-Reply-To: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
References: <8Fc-I6bfdYGGsRQituOy8XKudgWknmK4f9oAKWPh3V8=.93115956-0d5f-410b-8d0b-03ec9e3fdcfe@github.com>
Message-ID: <0bOuEeMxNo7BkkIDoJIYVsg7FqaQQHgYC0CiYOdkDyo=.9fbc82eb-5d81-469e-ad40-3ddb65bc1d69@github.com>

On Thu, 27 Nov 2025 13:03:28 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> Use `HttpResponse::connectionLabel` instead of `Http2TestExchange::connectionKey` to identify the connection request-response exchange is performed on, for the latter can accidentally return the same identifier again, e.g., if a closed connection is immediately reused.

This pull request has now been integrated.

Changeset: 78b155b2
Author:    Volkan Yazici <vyazici at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78b155b2b5745fc88c13586f93b632f61e038a94
Stats:     5 lines in 1 file changed: 0 ins; 1 del; 4 mod

8372147: ConnectionFlowControlTest should use HttpResponse.connectionLabel()

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28534

From dfuchs at openjdk.org  Fri Nov 28 14:48:47 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 28 Nov 2025 14:48:47 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v6]
In-Reply-To: <AuY0UhgGHQweAwCDUQNd0BvXmHyHBhDp2cBg6n2G9o0=.9e9d24be-f03b-4c59-a0e2-eba2ebf12859@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <AuY0UhgGHQweAwCDUQNd0BvXmHyHBhDp2cBg6n2G9o0=.9e9d24be-f03b-4c59-a0e2-eba2ebf12859@github.com>
Message-ID: <xtmhUkmLXHpSwMK59SeISNiT3cS0B30wcZdbYv7ESh4=.65f10455-c041-411f-a7e6-358d35e13f15@github.com>

On Fri, 28 Nov 2025 11:46:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
>> 
>> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
>> 
>> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
>> 
>> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
>> 
>> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those reques...
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - merge latest from master branch
>  - don't explicitly generate QUIC traffic for connection marked as finalStream
>  - Daniel's suggestion - remove Math.addExact() calls
>  - merge latest from master branch
>  - remove unwanted file
>  - fix duration overflow issue with Duration.toMillis()
>  - fix unintended check
>  - merge latest from master branch
>  - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

Thanks for taking on the feedback!

All tests look stable - so LGTM.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28522#pullrequestreview-3519248991

From jpai at openjdk.org  Sat Nov 29 01:29:03 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Nov 2025 01:29:03 GMT
Subject: RFR: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout [v6]
In-Reply-To: <AuY0UhgGHQweAwCDUQNd0BvXmHyHBhDp2cBg6n2G9o0=.9e9d24be-f03b-4c59-a0e2-eba2ebf12859@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
 <AuY0UhgGHQweAwCDUQNd0BvXmHyHBhDp2cBg6n2G9o0=.9e9d24be-f03b-4c59-a0e2-eba2ebf12859@github.com>
Message-ID: <ATI2CJUzve0xHpm5cAyRWmqxhKaU3p5w6Ldaza4xF8g=.46d8d690-341b-49d9-803b-44e7937bfcf0@github.com>

On Fri, 28 Nov 2025 11:46:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
>> 
>> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
>> 
>> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
>> 
>> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
>> 
>> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those reques...
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - merge latest from master branch
>  - don't explicitly generate QUIC traffic for connection marked as finalStream
>  - Daniel's suggestion - remove Math.addExact() calls
>  - merge latest from master branch
>  - remove unwanted file
>  - fix duration overflow issue with Duration.toMillis()
>  - fix unintended check
>  - merge latest from master branch
>  - 8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

Thank you Daniel for the review. My test repeat and tier testing completed normally too. I'll go ahead and integrate this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28522#issuecomment-3590779045

From jpai at openjdk.org  Sat Nov 29 01:29:05 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Nov 2025 01:29:05 GMT
Subject: Integrated: 8371802: Do not let QUIC connection to idle terminate when
 HTTP/3 is configured with a higher idle timeout
In-Reply-To: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
References: <to1J3MS47koHGfBqoIST9Gd0PhWz5tS9oDCLcI7nhAU=.df43ec60-7a18-4031-82fd-29d0b98c082b@github.com>
Message-ID: <XzGC2yP8Z1NZJppwgf5DOunZyPWtH1xv74zprW5kVJc=.fca59449-428c-4bb7-8a2c-ef474805b5c7@github.com>

On Thu, 27 Nov 2025 05:10:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to implement the enhancement noted in https://bugs.openjdk.org/browse/JDK-8371802?
> 
> QUIC specification allows for each endpoint of a connection to state their choice of idle timeout for the connection. The minimum of the two is then considered to be the effective idle timeout. Upon idle timeout, QUIC specifies that each endpoint can silently drop the connection (without sending any kind of notification to the other side).
> 
> In the JDK's implementation of HTTP/3, which sits on top of QUIC, applications are allowed to specify how long they want an established HTTP/3 connection to stay idle in the connection pool. For HTTP/3 the definition of idle is when there is no request/response currently in progress on that connection. If the HTTP/3 connection stays idle past that timeout then the connection will send a GOAWAY frame to the other side of the connection and gracefully terminate the connection.
> 
> Given that applications are allowed to configure this HTTP/3 idle timeout value, it then means that the QUIC layer shouldn't be allowed to silently idle terminate that connection if there's no traffic on that connection for a period equal or longer than the QUIC idle timeout. In theory, one could expect applications to configure a high QUIC idle timeout to match the HTTP/3 idle timeout, but in reality since the QUIC idle timeout is a minimum of the idle timeouts advertized by the server and the client of a connection, the (client side of the) application alone cannot control that value. Thus the QUIC layer needs to co-ordinate with the higher application layer (HTTP/3 in this case) to regularly check if any explicit traffic needs to be generated by QUIC to keep the connection from idle terminating. Furthermore, this kind of co-ordination and traffic generation (for example, through a PING frame) is allowed by the QUIC specification.
> 
> The changes in this PR introduce that co-ordination and send a `PING` frame from the QUIC layer if the HTTP/3 layer states that explicit traffic generation is necessary. The HTTP/3 connection will expect QUIC to generate this explicit traffic only when the HTTP/3 connection is in the pool and there are no HTTP request/responses currently in progress on that connection. If there is absence of traffic on the connection when there are HTTP request/responses in progress, then HTTP/3 doesn't expect QUIC to generate explicit traffic and instead expects that those request/responses would ...

This pull request has now been integrated.

Changeset: 92e1357d
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92e1357dfd2d874ef1a62ddd69c86a7bb189c6a2
Stats:     627 lines in 8 files changed: 528 ins; 50 del; 49 mod

8371802: Do not let QUIC connection to idle terminate when HTTP/3 is configured with a higher idle timeout

Reviewed-by: dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/28522

From dyama at openjdk.org  Sun Nov 30 15:17:54 2025
From: dyama at openjdk.org (Daisuke Yamazaki)
Date: Sun, 30 Nov 2025 15:17:54 GMT
Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server
 [v12]
In-Reply-To: <hCIXQ-ro8VKN0iJurKHZveAFDZ528hf27x-LrTkSYZA=.800135cf-c735-4904-ace3-3879f69e8bdf@github.com>
References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com>
 <BkKKQhFzjR0ezI-X5a-Mq5EjO0Hw2J2_qbXFY0QfUoU=.1b2ba3c3-0bc7-4b75-8232-b464781347db@github.com>
 <hCIXQ-ro8VKN0iJurKHZveAFDZ528hf27x-LrTkSYZA=.800135cf-c735-4904-ace3-3879f69e8bdf@github.com>
Message-ID: <7X_e_fAVnGZEUrvTVmrhfTGUlB1M53X1ha_1zZKAKeE=.b15051e1-58fd-4bb6-80ae-044ccd9d9c51@github.com>

On Fri, 14 Nov 2025 14:56:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Daisuke Yamazaki has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace IOException with EOFException for unexpected EOF in FileServerHandler
>
> test/jdk/com/sun/net/httpserver/simpleserver/FileServerHandlerTest.java line 146:
> 
>> 144:                         1000L, "bytes=100-199,300-399,150-350",
>> 145:                         new FileServerHandler.RangeEntry(100,399)
>> 146:                 },
> 
> Can we add a test with duplicated ranges too? e.g.
> 
> `0-99,200-399,0-99,400-499,200-499`

I added a test case for duplicated ranges, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2573900611