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