From pavel.rappo at gmail.com Wed Oct 1 10:14:01 2025 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Wed, 1 Oct 2025 11:14:01 +0100 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl In-Reply-To: References: Message-ID: This belongs to the net-dev mailing list, which I CC'ed. On Wed, Oct 1, 2025 at 10:56?AM Micha? G. wrote: > > Hi all, > > I recently ran into an issue with HttpClientImpl where I wanted to handle the reply right after calling sendAsync. What surprised me is that the returned CompletableFuture already runs on the commonPool, instead of using the executor I provided to the HttpClient. > > Looking into the implementation, I noticed this piece of code: > > // makes sure that any dependent actions happen in the CF default > // executor. This is only needed for sendAsync(...), when > // exchangeExecutor is non-null. > if (exchangeExecutor != null) { > res = res.whenCompleteAsync((r, t) -> { /* do nothing */}, ASYNC_POOL); > } > > I understand that this exchangeExecutor is meant to cover the request/response exchange itself, not necessarily the CompletableFuture chaining. But the fact that we always force the returned future back onto the commonPool, without any way to change this, feels quite limiting. > > In environments where the commonPool is already heavily loaded, this can easily introduce performance issues or unpredictable behavior. And since > > private static final Executor ASYNC_POOL = new CompletableFuture().defaultExecutor(); > > is fixed and cannot be replaced, users don?t have any way around it. For comparison, the default executor for CompletableFuture.supplyAsync or for parallelStream() is also the commonPool, but in those cases it?s easy to override it with a custom executor. It would be nice if HttpClientImpl offered the same flexibility. > > This is why I?d like to propose a change: when creating an HttpClientImpl, it should be possible to specify not only the exchange executor, but also the executor used for the returned CompletableFuture > > This would be backwards compatible (just an additional optional builder parameter), and it could bring several benefits: > > reduced context switching for clients that care about which thread executes response handling, > > more predictable performance in environments where commonPool is shared with other workloads, > > easier integration with frameworks that already manage their own executors, > > clearer control and observability over where callbacks are executed. > > Would such a change make sense, or is there a strong reason why we must always fallback to the commonPool? From bpb at openjdk.org Wed Oct 1 16:43:10 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 1 Oct 2025 16:43:10 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v16] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - 8337143: Clean up to address reviewer comments - ... and 6 more: https://git.openjdk.org/jdk/compare/fe9dbcc4...498be60b ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=15 Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From dfuchs at openjdk.org Thu Oct 2 15:22:57 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 2 Oct 2025 15:22:57 GMT Subject: RFR: 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout [v2] In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 06:42:09 GMT, Jaikiran Pai wrote: > Hello Daniel, this looks OK to me, but is the addition of othervm intentional? The PR description seems to suggest it is, but I couldn't see why that would be needed. It is not absolutely necessary but I'm suspicious of using the agentvm for tests that do networking. Especially when they fail in timeout. In addition it gets in the way when we want to be able to enable debug traces temporarilly (which requires system props) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27492#issuecomment-3361717528 From dfuchs at openjdk.org Thu Oct 2 15:22:59 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 2 Oct 2025 15:22:59 GMT Subject: Integrated: 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout In-Reply-To: References: Message-ID: On Thu, 25 Sep 2025 15:54:42 GMT, Daniel Fuchs wrote: > Hi, > > The H3ServerPushTest.java has been observed failing once in the CI on a personal job. > Analysis reveals that the test actually passed, but the timeout handler killed the test. > > > SUCCESSFUL H3ServerPushTest::testExcessivePushResponsesWithDistinctIdsInOneResponse 'testExcessivePushResponsesWithDistinctIdsInOneResponse(TestInfo)' [2840ms] > > [ JUnit Containers: found 4, started 4, succeeded 4, failed 0, aborted 0, skipped 0] > [ JUnit Tests: found 17, started 17, succeeded 17, failed 0, aborted 0, skipped 0] > > JavaTest Message: Test complete. > ... > result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 > > test result: Error. "junit" action timed out with a timeout of 120 seconds on agent 23 > > > This is probably attributable to the change of timeoutFactor to timeoutFactor=1, this change proposes to use othervm double the default timeout for that test to `/othervm/timeout=240` . This pull request has now been integrated. Changeset: 7ad9bdef Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/7ad9bdef1ed250a824ee9dee69b37bbcc8f7c924 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8368630: java/net/httpclient/http3/H3ServerPushTest.java succeeds but fails in jtreg timeout Reviewed-by: syan, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27492 From mchhipa at openjdk.org Thu Oct 2 18:49:24 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Thu, 2 Oct 2025 18:49:24 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer Message-ID: Update SimpleHttpServer class to use SimpleFileServer. ------------- Commit messages: - JDK-8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer Changes: https://git.openjdk.org/jdk/pull/27608/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367114 Stats: 96 lines in 1 file changed: 0 ins; 92 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From mchhipa at openjdk.org Thu Oct 2 18:49:24 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Thu, 2 Oct 2025 18:49:24 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. Hi @JoeWang-Java , @dfuch , Could you please review this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3362513799 From vyazici at openjdk.org Thu Oct 2 19:45:46 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 2 Oct 2025 19:45:46 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: <-GJqrtP7vX443Naj6R2y4gCf5CjKtHx5eMRLX-m8fn4=.27c3c019-4e24-4306-9e14-507a1b313329@github.com> On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. Nice clean up, thanks @mahendrachhipa! ? I see that Tier1-3 pass, LGTM. ------------- Marked as reviewed by vyazici (Committer). PR Review: https://git.openjdk.org/jdk/pull/27608#pullrequestreview-3296154646 From duke at openjdk.org Thu Oct 2 20:13:29 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 2 Oct 2025 20:13:29 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability Message-ID: As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. ------------- Commit messages: - Improve HttpExchange.sendResponseHeaders usability Changes: https://git.openjdk.org/jdk/pull/27613/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27613&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368955 Stats: 20 lines in 1 file changed: 12 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27613/head:pull/27613 PR: https://git.openjdk.org/jdk/pull/27613 From jpai at openjdk.org Fri Oct 3 04:52:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 04:52:46 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 20:06:14 GMT, Josiah Noel wrote: > As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. Hello Josiah, it's good to see these changes. I've added just a few trivial review comments inline. The copyright year on the file will need an update to `2005, 2025,`. src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 75: > 73: > 74: /** > 75: * No response body is being sent with this response Nit - instead of "with this response", it might be better to say "with the response" ------------- PR Review: https://git.openjdk.org/jdk/pull/27613#pullrequestreview-3297400085 PR Review Comment: https://git.openjdk.org/jdk/pull/27613#discussion_r2400776031 From jpai at openjdk.org Fri Oct 3 04:55:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 04:55:45 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 20:06:14 GMT, Josiah Noel wrote: > As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 80: > 78: > 79: /** > 80: * The response body is unspecified and will be chunk encoded Nit - maybe reword this as "The response body will be chunk encoded" and remove any mention of unspecified? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27613#discussion_r2400778737 From duke at openjdk.org Fri Oct 3 05:00:50 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 3 Oct 2025 05:00:50 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: > As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: pr comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27613/files - new: https://git.openjdk.org/jdk/pull/27613/files/3a4de5c5..d1d7c612 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27613&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27613&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27613/head:pull/27613 PR: https://git.openjdk.org/jdk/pull/27613 From duke at openjdk.org Fri Oct 3 05:06:51 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 3 Oct 2025 05:06:51 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 14:25:36 GMT, Daniel Fuchs wrote: > I intend to do a more thorough review in the coming days. I'm sure that when you get time to review in earnest, you'll find it quite hard to believe that these changes have any relation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3364267918 From jpai at openjdk.org Fri Oct 3 05:14:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 05:14:50 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 04:52:59 GMT, Jaikiran Pai wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> pr comments > > src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 80: > >> 78: >> 79: /** >> 80: * The response body is unspecified and will be chunk encoded > > Nit - maybe reword this as "The response body will be chunk encoded" and remove any mention of unspecified? Additionally, both these new fields should have a `@since 26`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27613#discussion_r2400811184 From jpai at openjdk.org Fri Oct 3 05:14:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 05:14:52 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:00:50 GMT, Josiah Noel wrote: >> As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > pr comments src/jdk.httpserver/share/classes/com/sun/net/httpserver/HttpExchange.java line 180: > 178: * Starts sending the final response back to the client using the current set of > 179: * response headers obtained from {@link #getResponseHeaders()} and the numeric > 180: * response code as specified in this I think specifying "response headers obtained from {@link #getResponseHeaders()}" will imply that the implementation of `sendResponseHeaders(int rCode, long responseLength)` is now going to always call `getResponseHeaders()`. That would be a new expectation of this method. I went through the entire text of this method javadoc and I even spotted a pre-existing typo in the param doc of `@param responseLength` (the getResponseCode() reference in that text should be getResponseBody()). Would rewording this entire API doc to something like this be better: /** * Starts sending the final response back to the client using the current set of * response headers and the numeric response code {@code rCode}. *

* If the given {@code responseLength} is greater than {@code zero}, this * specifies an exact number of bytes to send and the application must send * that exact amount of data. If {@code responseLength} is * {@link #RSPBODY_CHUNKED} then the response body uses * chunked transfer encoding and an arbitrary amount of data may be * sent. If {@code responseLength} is {@link #RSPBODY_EMPTY} then no * response body should be sent. *

* The application terminates the response body by closing the * {@link OutputStream}. *

* If the {@code content-length} response header has not already been set then * this is set to the appropriate value depending on the {@code responseLength}. *

* This method must be called prior to calling {@link #getResponseBody()}. * * @implNote This implementation allows the caller to instruct the * server to force a connection close after the exchange terminates, by * supplying a {@code Connection: close} header through {@linkplain * #getResponseHeaders() response headers} before {@code sendResponseHeaders} * is called. * * @param rCode the response code to send * @param responseLength if {@literal > 0}, specifies a fixed response body * length and that exact number of bytes must be written * to the stream acquired from {@link #getResponseBody()} * If equal to {@link #RSPBODY_CHUNKED}, then chunked encoding is used, * and an arbitrary number of bytes may be written. * If equal to {@link #RSPBODY_EMPTY}, then the response will not * have a body and no response body may be written. * @throws IOException if the response headers have already been sent or an I/O error occurs * @see HttpExchange#getResponseBody() */ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27613#discussion_r2400810787 From duke at openjdk.org Fri Oct 3 05:31:45 2025 From: duke at openjdk.org (Ethan McCue) Date: Fri, 3 Oct 2025 05:31:45 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:00:50 GMT, Josiah Noel wrote: >> As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > pr comments I hate to continue being the curmudgeon in the room, but I think this shares a lot of the downsides that #8331195 had. Sorry on github that was #18955 https://github.com/openjdk/jdk/pull/18955 This basically only solves for the very specific case of 1. You know, up front, that you are sending an empty response 2. You are aware these methods exist. As an exercise, how would you write: void sendStringResponse(HttpExchange exchange, int status, String body) { // ... } ------------- PR Comment: https://git.openjdk.org/jdk/pull/27613#issuecomment-3364310278 PR Comment: https://git.openjdk.org/jdk/pull/27613#issuecomment-3364315044 From jpai at openjdk.org Fri Oct 3 05:36:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 05:36:45 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: <0wdfY8mtBcpaQQx0GmUu2iGyvqYRVQlpKZjVyo770fY=.8cd2fb63-b204-405d-bd4a-7150f7f688b0@github.com> On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. Hello Mahendra, it's good that we are moving to use the `com.sun.net.httpserver.SimpleFileServer` in this test library class. However, it looks like before this change, this test library class was using a `Executor` which allowed it to handle multiple requests concurrently and thus serve the files concurrently. With this change, the requests will now be handled serially because the lack of any executor being configured on the internal `HttpServer` instance backing the `SimpleFileServer` instance. Looking at the references of this `jdk.test.lib.net.SimpleHttpServer` test library class, I see only 3 tests using it. I wonder if we should just delete this class altogether and instead using the the `SimpleFileServer` at the call sites as and how necessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/27608#pullrequestreview-3297482783 From duke at openjdk.org Fri Oct 3 05:42:21 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 3 Oct 2025 05:42:21 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v3] In-Reply-To: References: Message-ID: <_tfGiKMKBAPeMP0t1ZO6DH1GsZU9fwnwghdxxSCS-wA=.a95cf95e-0157-438d-b040-179bef12cef0@github.com> > As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update HttpExchange.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27613/files - new: https://git.openjdk.org/jdk/pull/27613/files/d1d7c612..f78aa328 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27613&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27613&range=01-02 Stats: 23 lines in 1 file changed: 3 ins; 5 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27613.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27613/head:pull/27613 PR: https://git.openjdk.org/jdk/pull/27613 From alanb at openjdk.org Fri Oct 3 05:42:23 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Oct 2025 05:42:23 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: <0Mlg9Yfw06X_AHvJCDBpNzve47jY6zhmXzOPFYJ5tK8=.47519823-69b4-49c4-9fae-2f2023f6671a@github.com> On Fri, 3 Oct 2025 05:00:50 GMT, Josiah Noel wrote: >> As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > pr comments @SentryMan - I see JDK-8368955 is assigned @Michael-Mc-Mahon and it seems to working on it, did you check with them before creating this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27613#issuecomment-3364331836 From jpai at openjdk.org Fri Oct 3 05:44:45 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 05:44:45 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. Interestingly, there's even a `test/jdk/com/sun/net/httpserver/SimpleFileServer.java` class which is neither a test nor a test library class. As far as I can see, it's not being used anywhere. Maybe we should remove that one too. These similarly named classes add to confusion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3364337804 From duke at openjdk.org Fri Oct 3 05:49:45 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 3 Oct 2025 05:49:45 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:29:34 GMT, Ethan McCue wrote: > This basically only solves for the very specific case of I didn't add any methods. > I see JDK-8368955 is assigned @Michael-Mc-Mahon and it seems to working on it, did you check with them before creating this PR? Apologies, I got caught up in the moment after perceiving the ticket created but no PR after a few days. I can close ------------- PR Comment: https://git.openjdk.org/jdk/pull/27613#issuecomment-3364348245 From duke at openjdk.org Fri Oct 3 05:49:45 2025 From: duke at openjdk.org (Ethan McCue) Date: Fri, 3 Oct 2025 05:49:45 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: <6IfMLaFEXLZUZFfVJf9aJiyRt6ipEzJBvc8r8Rate24=.592eee3e-de2b-47c7-aae7-13725e0cdc49@github.com> On Fri, 3 Oct 2025 05:46:58 GMT, Josiah Noel wrote: > I didn't add any methods. *fields, my bad ------------- PR Comment: https://git.openjdk.org/jdk/pull/27613#issuecomment-3364349051 From alanb at openjdk.org Fri Oct 3 06:00:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Oct 2025 06:00:57 GMT Subject: RFR: 8368955: Improve HttpExchange.sendResponseHeaders usability [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:46:58 GMT, Josiah Noel wrote: > Apologies, I got caught up in the moment after perceiving the ticket created but no PR after a few days. I can close Best to be polite and check with the person assigned to the issue first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27613#issuecomment-3364369676 From duke at openjdk.org Fri Oct 3 06:00:58 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 3 Oct 2025 06:00:58 GMT Subject: Withdrawn: 8368955: Improve HttpExchange.sendResponseHeaders usability In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 20:06:14 GMT, Josiah Noel wrote: > As specified in [JDK-8368955](https://bugs.openjdk.org/browse/JDK-8368955?jql=project%20in%20(JDK)%20AND%20component%20in%20(core-libs)%20AND%20Subcomponent%20in%20(java.net)), adds some constants to HttpExchange to make `sendResponseHeaders` more usable. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27613 From jpai at openjdk.org Fri Oct 3 07:20:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 3 Oct 2025 07:20:43 GMT Subject: RFR: 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed Message-ID: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> Can I please get a review of this test-only change which addresses intermittent failures in `GetHTTP3Test` and `PostHTTP3Test`? As noted in https://bugs.openjdk.org/browse/JDK-8368821, these two tests have been reported to fail intermittently, especially when the host on which it runs is under heavy resource usage or when run with JVM options like `-Xcomp`. The commit in this PR removes the connection timeout that was enforced on the connection attempts by the test. As far as I can see, they aren't necessary for what this test is testing. The change also updates a few other places in this test which had specific values for timeouts when checking if the `HttpClient` had shutdown. These places have been updated to take into account the timeout factor when computing the timeout. The changes have been verified by Matthias and SendaoYan who originally reported these issues. I will run this change in our CI too before integrating. ------------- Commit messages: - 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed Changes: https://git.openjdk.org/jdk/pull/27619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368821 Stats: 15 lines in 2 files changed: 4 ins; 4 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27619.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27619/head:pull/27619 PR: https://git.openjdk.org/jdk/pull/27619 From dfuchs at openjdk.org Fri Oct 3 10:08:48 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 10:08:48 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. The SimpleHttpServer class that Mahendra is updating is used by multi-relase jars and jaxp catalog tests. It could be prudent to update the class first, check that everything remains stable, and then replace usage in a followup issue. It seems this class is only being used by three tests however - so maybe updating those three tests to use the SimpleFileServer directly won't be too bad. If we do that then make sure we keep the same behaviour = keep the executor as @jaikiran suggested. Good find about `test/jdk/com/sun/net/httpserver/SimpleFileServer.java` - let's attempt to remove it - it does not appear to be used anywhere. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3365124225 From michaelm at openjdk.org Fri Oct 3 10:26:48 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 3 Oct 2025 10:26:48 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:03:53 GMT, Josiah Noel wrote: >>> That is pretty sus, because this PR should only change behavior for 1xx codes. >> >> Right. Emphasis on the 'should' :-) I haven't actually reviewed the proposed changes, just gave them a cursory look. This was just a guinea pig test run experiment to see if any tests would fail consistently and try to catch early mistakes. >> I intend to do a more thorough review in the coming days. >> >> The state management in the HttpServer is far from obvious - and stop() relies on the state to be accurate. stop() happens asynchronously, which adds opportunity for more races. That failing test is kind of timeout dependent - so it is possible that it will fail on overloaded machines. That said - I didn't see evidence in the log that the test was executing slower that usual, and I haven't seen that test failing before in the CI. I will need to investigate more (which will take time). > >> I intend to do a more thorough review in the coming days. > > I'm sure that when you get time to review in earnest, you'll find it quite hard to believe that these changes have any relation. I'm okay with @SentryMan fixing this. I filed another issue for the API change that I suggested (https://bugs.openjdk.org/browse/JDK-8368955) and I will open a PR for that after this issue is fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3365172701 From dfuchs at openjdk.org Fri Oct 3 10:30:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 10:30:45 GMT Subject: RFR: 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed In-Reply-To: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> References: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> Message-ID: On Fri, 3 Oct 2025 07:13:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses intermittent failures in `GetHTTP3Test` and `PostHTTP3Test`? > > As noted in https://bugs.openjdk.org/browse/JDK-8368821, these two tests have been reported to fail intermittently, especially when the host on which it runs is under heavy resource usage or when run with JVM options like `-Xcomp`. > > The commit in this PR removes the connection timeout that was enforced on the connection attempts by the test. As far as I can see, they aren't necessary for what this test is testing. The change also updates a few other places in this test which had specific values for timeouts when checking if the `HttpClient` had shutdown. These places have been updated to take into account the timeout factor when computing the timeout. > > The changes have been verified by Matthias and SendaoYan who originally reported these issues. I will run this change in our CI too before integrating. The proposed changes look good to me. I agree that the connection timeout is not needed for the purpose of the test. It might have been added to fail the test earlier while working on the implementation and running the test locally, but if it causes trouble in higher tiers I believe we can remove it safely. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27619#pullrequestreview-3298382070 From dfuchs at openjdk.org Fri Oct 3 10:57:51 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 10:57:51 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:03:53 GMT, Josiah Noel wrote: > I'm sure that when you get time to review in earnest, you'll find it quite hard to believe that these changes have any relation. Right. I still haven't got to that point, but I have seen that test failing frequently enough without your changes - so I am now confident the failures are unrelated to your changes. I have logged [JDK-8368625](https://bugs.openjdk.org/browse/JDK-8368625) to follow up on that test issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3365251379 From vyazici at openjdk.org Fri Oct 3 13:21:18 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 3 Oct 2025 13:21:18 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup Message-ID: Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. ------------- Commit messages: - Replace `ThreadTracker` usage with `ScopedValue` in `java.net.URL` Changes: https://git.openjdk.org/jdk/pull/27623/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27623&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366040 Stats: 84 lines in 3 files changed: 65 ins; 14 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27623.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27623/head:pull/27623 PR: https://git.openjdk.org/jdk/pull/27623 From vyazici at openjdk.org Fri Oct 3 13:21:19 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 3 Oct 2025 13:21:19 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 13:14:43 GMT, Volkan Yazici wrote: > Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. Passing `tier1,2` results are attached to the ticket. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27623#issuecomment-3365646510 From dfuchs at openjdk.org Fri Oct 3 16:41:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 16:41:54 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 13:14:43 GMT, Volkan Yazici wrote: > Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. src/java.base/share/classes/java/net/URL.java line 1402: > 1400: throw new Error("Circular loading of URL stream handler providers detected"); > 1401: } > 1402: return ScopedValue.where(IN_LOOKUP, true).call(() -> { We should never reach here if the VM is not booted, or if the protocol is `file:` or `jrt:` - so it may be safe to use a lambda. The alternative would be to use an anonymous class and create a `new Runnable() { ... }` but it's probably not needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27623#discussion_r2402580089 From alanb at openjdk.org Fri Oct 3 17:15:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Oct 2025 17:15:45 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 16:38:50 GMT, Daniel Fuchs wrote: >> Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. > > src/java.base/share/classes/java/net/URL.java line 1402: > >> 1400: throw new Error("Circular loading of URL stream handler providers detected"); >> 1401: } >> 1402: return ScopedValue.where(IN_LOOKUP, true).call(() -> { > > We should never reach here if the VM is not booted, or if the protocol is `file:` or `jrt:` - so it may be safe to use a lambda. The alternative would be to use an anonymous class and create a `new Runnable() { ... }` but it's probably not needed. The changes to URL look okay but good to run any startup benchmarks to check startup performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27623#discussion_r2402698820 From alanb at openjdk.org Fri Oct 3 17:22:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 3 Oct 2025 17:22:46 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 13:14:43 GMT, Volkan Yazici wrote: > Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java line 143: > 141: TEST_SRC.resolve("circular.provider.template"), > 142: sysProps); > 143: } I assume you've re-format the changes to Basic.java to be consistent with this existing code in the test (looks a bit strange on first sighting to see a completely different style being introduced). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27623#discussion_r2402719125 From daniel.fuchs at oracle.com Fri Oct 3 17:24:06 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 3 Oct 2025 18:24:06 +0100 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl In-Reply-To: References: Message-ID: <793ff557-4ecf-428c-bea7-23784d169ef3@oracle.com> Hi Michal, >> Would such a change make sense, or is there a strong reason why we must always fallback to the commonPool? The HttpClient executor is used by the HttpClient for its own purpose, which is to execute small (usually non-blocking) asynchronous tasks. In my todo list I have a task to add an `@implNote` or `@apiNote` to better explain how the HttpClient uses the executor, and why tasks submitted to the executor must always be executed. The idea was that no blocking code would run in that executor, so it should be possible to configure the client with an executor using a very small number of threads (or even an executor that run tasks inline). In practice custom BodyPublishers/BodyHandlers/BodySubscribers may be invoked while running in the executor, so it's hard to guarantee that no blocking code would be invoked, but these should adhere to the reactive stream specification, and thus, if they adhere to the spec, do nothing blocking. Custom dependent actions that are added by the caller to a CompletableFuture returned by sendAsync() have however no such requirements, and nothing is there to prevent them from doing blocking operations. Blocking in the HttpClient executor would be bad, as it may lead to thread starvation and prevent requests/responses from eventually completing. This is why we forcefully ensure that such dependent actions are run in the Fork Join Pool instead. That said, with VirtualThreads being now available in the platform - I have been wondering whether we should just use VirtualThreads internally. There are still a few limitations with VirtualThreads pertaining to class loading and static initializers, so we haven't switched to that yet, but may do so in the future. If we eventually do, then maybe the HttpClient executor could be repurposed to execute (only) dependent actions. I am not sure we would like to configure the HttpClient with yet another executor however. How big an issue is this? best regards, -- daniel On 01/10/2025 11:14, Pavel Rappo wrote: > This belongs to the net-dev mailing list, which I CC'ed. > > On Wed, Oct 1, 2025 at 10:56?AM Micha? G. wrote: >> >> Hi all, >> >> I recently ran into an issue with HttpClientImpl where I wanted to handle the reply right after calling sendAsync. What surprised me is that the returned CompletableFuture already runs on the commonPool, instead of using the executor I provided to the HttpClient. >> >> Looking into the implementation, I noticed this piece of code: >> >> // makes sure that any dependent actions happen in the CF default >> // executor. This is only needed for sendAsync(...), when >> // exchangeExecutor is non-null. >> if (exchangeExecutor != null) { >> res = res.whenCompleteAsync((r, t) -> { /* do nothing */}, ASYNC_POOL); >> } >> >> I understand that this exchangeExecutor is meant to cover the request/response exchange itself, not necessarily the CompletableFuture chaining. But the fact that we always force the returned future back onto the commonPool, without any way to change this, feels quite limiting. >> >> In environments where the commonPool is already heavily loaded, this can easily introduce performance issues or unpredictable behavior. And since >> >> private static final Executor ASYNC_POOL = new CompletableFuture().defaultExecutor(); >> >> is fixed and cannot be replaced, users don?t have any way around it. For comparison, the default executor for CompletableFuture.supplyAsync or for parallelStream() is also the commonPool, but in those cases it?s easy to override it with a custom executor. It would be nice if HttpClientImpl offered the same flexibility. >> >> This is why I?d like to propose a change: when creating an HttpClientImpl, it should be possible to specify not only the exchange executor, but also the executor used for the returned CompletableFuture >> >> This would be backwards compatible (just an additional optional builder parameter), and it could bring several benefits: >> >> reduced context switching for clients that care about which thread executes response handling, >> >> more predictable performance in environments where commonPool is shared with other workloads, >> >> easier integration with frameworks that already manage their own executors, >> >> clearer control and observability over where callbacks are executed. >> >> Would such a change make sense, or is there a strong reason why we must always fallback to the commonPool? From mchhipa at openjdk.org Fri Oct 3 17:34:24 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 3 Oct 2025 17:34:24 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: References: Message-ID: > Update SimpleHttpServer class to use SimpleFileServer. Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27608/files - new: https://git.openjdk.org/jdk/pull/27608/files/15e71bba..64cad93a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=00-01 Stats: 187 lines in 5 files changed: 28 ins; 138 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From mchhipa at openjdk.org Fri Oct 3 17:40:47 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 3 Oct 2025 17:40:47 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: <0wdfY8mtBcpaQQx0GmUu2iGyvqYRVQlpKZjVyo770fY=.8cd2fb63-b204-405d-bd4a-7150f7f688b0@github.com> References: <0wdfY8mtBcpaQQx0GmUu2iGyvqYRVQlpKZjVyo770fY=.8cd2fb63-b204-405d-bd4a-7150f7f688b0@github.com> Message-ID: On Fri, 3 Oct 2025 05:33:41 GMT, Jaikiran Pai wrote: > Hello Mahendra, it's good that we are moving to use the `com.sun.net.httpserver.SimpleFileServer` in this test library class. However, it looks like before this change, this test library class was using a `Executor` which allowed it to handle multiple requests concurrently and thus serve the files concurrently. With this change, the requests will now be handled serially because the lack of any executor being configured on the internal `HttpServer` instance backing the `SimpleFileServer` instance. > > Looking at the references of this `jdk.test.lib.net.SimpleHttpServer` test library class, I see only 3 tests using it. I wonder if we should just delete this class altogether and instead using the the `SimpleFileServer` at the call sites as and how necessary. Thanks. Now SimpleFileServer is being used in tests and jdk.test.lib.net.SimpleHttpServer is deleted now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3366616592 From mchhipa at openjdk.org Fri Oct 3 17:44:46 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 3 Oct 2025 17:44:46 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 05:41:58 GMT, Jaikiran Pai wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Interestingly, there's even a `test/jdk/com/sun/net/httpserver/SimpleFileServer.java` class which is neither a test nor a test library class. As far as I can see, it's not being used anywhere. Maybe we should remove that one too. These similarly named classes add to confusion. > The SimpleHttpServer class that Mahendra is updating is used by multi-relase jars and jaxp catalog tests. It could be prudent to update the class first, check that everything remains stable, and then replace usage in a followup issue. It seems this class is only being used by three tests however - so maybe updating those three tests to use the SimpleFileServer directly won't be too bad. If we do that then make sure we keep the same behaviour = keep the executor as @jaikiran suggested. > > Good find about `test/jdk/com/sun/net/httpserver/SimpleFileServer.java` - let's attempt to remove it - it does not appear to be used anywhere. Thanks, Now test/jdk/com/sun/net/httpserver/SimpleFileServer.java is removed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27608#issuecomment-3366628509 From dfuchs at openjdk.org Fri Oct 3 17:54:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 17:54:49 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 17:34:24 GMT, Mahendra Chhipa wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java line 103: > 101: httpserver.start(); > 102: remoteFilePath = "http:" + jdk.test.lib.net.URIBuilder.newBuilder().host(httpserver.getAddress().getAddress()). > 103: port(httpserver.getAddress().getPort()).build().toString() + REMOTE_FILE_LOCATION; Suggestion: remoteFilePath = jdk.test.lib.net.URIBuilder.newBuilder() .scheme("http") .host(httpserver.getAddress().getAddress()) .port(httpserver.getAddress().getPort()) .build().toString() + REMOTE_FILE_LOCATION; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27608#discussion_r2402805191 From dfuchs at openjdk.org Fri Oct 3 17:54:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 3 Oct 2025 17:54:49 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 17:47:08 GMT, Daniel Fuchs wrote: >> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented review comments. > > test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java line 103: > >> 101: httpserver.start(); >> 102: remoteFilePath = "http:" + jdk.test.lib.net.URIBuilder.newBuilder().host(httpserver.getAddress().getAddress()). >> 103: port(httpserver.getAddress().getPort()).build().toString() + REMOTE_FILE_LOCATION; > > Suggestion: > > remoteFilePath = jdk.test.lib.net.URIBuilder.newBuilder() > .scheme("http") > .host(httpserver.getAddress().getAddress()) > .port(httpserver.getAddress().getPort()) > .build().toString() + REMOTE_FILE_LOCATION; Is there another URIBuilder that prevents importing `jdk.test.lib.net.URIBuilder`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27608#discussion_r2402812037 From sherman at openjdk.org Fri Oct 3 19:10:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 3 Oct 2025 19:10:20 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support Message-ID: ### Summary Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: **String.equalsIgnoreCase(String)** - Unicode-aware, locale-independent. - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. - Limited: does not support 1:M mapping defined in Unicode case folding. **Character.toLowerCase(int) / Character.toUpperCase(int)** - Locale-independent, single code point only. - No support for 1:M mappings. **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** - Based on Unicode SpecialCasing.txt, supports 1:M mappings. - Intended primarily for presentation/display, not structural case-insensitive matching. - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. **1:M mapping example, U+00DF (?)** - String.toUpperCase(Locale.ROOT, "?") ? "SS" - Case folding produces "ss", matching Unicode caseless comparison rules. jshell> "\u00df".equalsIgnoreCase("ss") $22 ==> false jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") $24 ==> true ### Motivation & Direction Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. - Unicode-compliant **full** case folding. - Simpler, stable and more efficient case-less matching without workarounds. - Brings Java's string comparison handling in line with other programming languages/libraries. This PR proposes to introduce the following comparison methods in `String` class - boolean equalsFoldCase(String anotherString) - int compareToFoldCase(String anotherString) - Comparator UNICODE_CASEFOLD_ORDER These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. ### The New API /** * Compares this {@code String} to another {@code String} for equality, * using Unicode case folding. Two strings are considered equal * by this method if their case-folded forms are identical. *

* Case folding is defined by the Unicode Standard in * CaseFolding.txt, * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")} * returns {@code true}, since the character {@code U+00DF} (sharp s) folds * to {@code "ss"}. *

* Case folding is locale-independent and language-neutral, unlike * locale-sensitive transformations such as {@link #toLowerCase()} or * {@link #toUpperCase()}. It is intended for caseless matching, * searching, and indexing. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #equalsIgnoreCase(String)}. It implements full case folding as * defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code equalsIgnoreCase}. * For example: * 

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }
* * @param anotherString * The {@code String} to compare this {@code String} against * * @return {@code true} if the given object is not {@code null} and represents * the same sequence of characters as this string under Unicode case * folding; {@code false} otherwise. * * @see #compareToFoldCase(String) * @see #equalsIgnoreCase(String) * @since 26 */ public boolean equalsFoldCase(String anotherString) /** * Compares two strings lexicographically using Unicode case folding. * This method returns an integer whose sign is that of calling {@code compareTo} * on the Unicode case folded version of the strings. Unicode Case folding * eliminates differences in case according to the Unicode Standard, using the * mappings defined in * CaseFolding.txt, * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}. *

* Case folding is a locale-independent, language-neutral form of case mapping, * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)}, * which applies a simpler locale-insensitive uppercase mapping. This method * follows the Unicode full case folding, providing stable and * consistent results across all environments. *

* Note that this method does not take locale into account, and may * produce results that differ from locale-sensitive ordering. Use * {@link java.text.Collator} for locale-sensitive comparison. * * @apiNote * This method is the Unicode-compliant alternative to * {@link #compareToIgnoreCase(String)}. It implements the full case folding * as defined by the Unicode Standard, which may differ from the simpler * per-character mapping performed by {@code compareToIgnoreCase}. * For example: * 

{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }
* * @param str the {@code String} to be compared. * @return a negative integer, zero, or a positive integer as the specified * String is greater than, equal to, or less than this String, * ignoring case considerations by case folding. * @see #equalsFoldCase(String) * @see #compareToIgnoreCase(String) * @see java.text.Collator * @since 26 */ public int compareToFoldCase(String str) /** * A Comparator that orders {@code String} objects as by * {@link #compareToFoldCase(String) compareToFoldCase()}. * * @see #compareToFoldCase(String) * @since 26 */ public static final Comparator UNICODE_CASEFOLD_ORDER; ### Usage Examples Sharp s (U+00DF) case-folds to "ss" "stra?e".equalsIgnoreCase("strasse"); // false "stra?e".compareToIgnoreCase("strasse"); // != 0 "stra?e".equalsFoldCase("strasse"); // true ### Performance The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing compareToIgnoreCase(). Benchmark Mode Cnt Score Error Units StringCompareToIgnoreCase.asciiGreekLower avgt 15 20.195 ? 0.300 ns/op StringCompareToIgnoreCase.asciiGreekLowerCF avgt 15 11.051 ? 0.254 ns/op StringCompareToIgnoreCase.asciiGreekUpperLower avgt 15 6.035 ? 0.047 ns/op StringCompareToIgnoreCase.asciiGreekUpperLowerCF avgt 15 14.786 ? 0.382 ns/op StringCompareToIgnoreCase.asciiLower avgt 15 17.688 ? 1.396 ns/op StringCompareToIgnoreCase.asciiLowerCF avgt 15 44.552 ? 0.155 ns/op StringCompareToIgnoreCase.asciiUpperLower avgt 15 13.069 ? 0.487 ns/op StringCompareToIgnoreCase.asciiUpperLowerCF avgt 15 58.684 ? 0.274 ns/op StringCompareToIgnoreCase.greekLower avgt 15 20.642 ? 0.082 ns/op StringCompareToIgnoreCase.greekLowerCF avgt 15 7.255 ? 0.271 ns/op StringCompareToIgnoreCase.greekUpperLower avgt 15 5.737 ? 0.013 ns/op StringCompareToIgnoreCase.greekUpperLowerCF avgt 15 11.100 ? 1.147 ns/op StringCompareToIgnoreCase.lower avgt 15 20.192 ? 0.044 ns/op StringCompareToIgnoreCase.lowerrCF avgt 15 11.257 ? 0.259 ns/op StringCompareToIgnoreCase.supLower avgt 15 54.801 ? 0.415 ns/op StringCompareToIgnoreCase.supLowerCF avgt 15 15.207 ? 0.418 ns/op StringCompareToIgnoreCase.supUpperLower avgt 15 14.431 ? 0.188 ns/op StringCompareToIgnoreCase.supUpperLowerCF avgt 15 19.149 ? 0.985 ns/op StringCompareToIgnoreCase.upperLower avgt 15 5.650 ? 0.051 ns/op StringCompareToIgnoreCase.upperLowerCF avgt 15 14.338 ? 0.352 ns/op StringCompareToIgnoreCase.utf16SubLower avgt 15 14.774 ? 0.200 ns/op StringCompareToIgnoreCase.utf16SubLowerCF avgt 15 2.669 ? 0.041 ns/op StringCompareToIgnoreCase.utf16SupUpperLower avgt 15 16.250 ? 0.099 ns/op StringCompareToIgnoreCase.utf16SupUpperLowerCF avgt 15 11.524 ? 0.327 ns/op ### Refs [Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790) [Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping) [Unicode Technical Standard #18: Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches) [Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt) [Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt) ### Other Languages **Python string.casefold()** The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons. **Perl?s fc()** Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings. Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case. Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. **ICU4J UCharacter.foldCase (Java)** Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF). Method Signature (String based): public static String foldCase(String str, int options) Method Signature (CharSequence & Appendable based): public static A foldCase(CharSequence src, A dest, int options, Edits edits) Key Features: Case Folding: Converts a string to its case-folded equivalent. Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings. Context Insensitive: The mapping of a character is not affected by surrounding characters. Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text. Result Length: The resulting string can be longer or shorter than the original. Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes. **u_strFoldCase (C/C++)** A lower-level C API function for case folding a string. Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior. Availability: Found in the ustring.h and unistr.h headers in the ICU4C library. ------------- Commit messages: - 8365675: Add String Unicode Case-Folding Support Changes: https://git.openjdk.org/jdk/pull/26892/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365675 Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/26892.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892 PR: https://git.openjdk.org/jdk/pull/26892 From jpai at openjdk.org Sat Oct 4 08:11:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Oct 2025 08:11:58 GMT Subject: RFR: 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed In-Reply-To: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> References: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> Message-ID: <2HGP9dyAatQF6tjRijbS4lzEKKLjDN4ahaY8CV2JTqM=.22dbe28b-b43e-4d68-a3cf-9ec1a2f88996@github.com> On Fri, 3 Oct 2025 07:13:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses intermittent failures in `GetHTTP3Test` and `PostHTTP3Test`? > > As noted in https://bugs.openjdk.org/browse/JDK-8368821, these two tests have been reported to fail intermittently, especially when the host on which it runs is under heavy resource usage or when run with JVM options like `-Xcomp`. > > The commit in this PR removes the connection timeout that was enforced on the connection attempts by the test. As far as I can see, they aren't necessary for what this test is testing. The change also updates a few other places in this test which had specific values for timeouts when checking if the `HttpClient` had shutdown. These places have been updated to take into account the timeout factor when computing the timeout. > > The changes have been verified by Matthias and SendaoYan who originally reported these issues. I will run this change in our CI too before integrating. Thank you Daniel for the review. tier testing with these changes in our CI came back fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27619#issuecomment-3368010818 From jpai at openjdk.org Sat Oct 4 08:11:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Oct 2025 08:11:59 GMT Subject: Integrated: 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed In-Reply-To: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> References: <9Gctjb31TX4vLt98ZFP81dd92y_6IEVfQF4Qed9B-uM=.a59376d7-dee1-481e-bd59-88ece79d699a@github.com> Message-ID: On Fri, 3 Oct 2025 07:13:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses intermittent failures in `GetHTTP3Test` and `PostHTTP3Test`? > > As noted in https://bugs.openjdk.org/browse/JDK-8368821, these two tests have been reported to fail intermittently, especially when the host on which it runs is under heavy resource usage or when run with JVM options like `-Xcomp`. > > The commit in this PR removes the connection timeout that was enforced on the connection attempts by the test. As far as I can see, they aren't necessary for what this test is testing. The change also updates a few other places in this test which had specific values for timeouts when checking if the `HttpClient` had shutdown. These places have been updated to take into account the timeout factor when computing the timeout. > > The changes have been verified by Matthias and SendaoYan who originally reported these issues. I will run this change in our CI too before integrating. This pull request has now been integrated. Changeset: 76dba201 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/76dba201fa1a525780677e4d3dee8e9ffafd1cd7 Stats: 15 lines in 2 files changed: 4 ins; 4 del; 7 mod 8368821: Test java/net/httpclient/http3/GetHTTP3Test.java intermittently fails with java.io.IOException: QUIC endpoint closed Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27619 From jpai at openjdk.org Sat Oct 4 16:29:12 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Oct 2025 16:29:12 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak Message-ID: Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: Path regularFile = Path.of("hello.txt"); URLConnection conn = regularFile.toUri().toURL().openConnection(); // either of the following header related APIs long val = conn.getLastModified(); String val = conn.getHeaderField("foobar"); // ... some other header related APIs The issue/leak arises in these cases. Application code constructs a `URLConnection` and invokes these trivial APIs and neither does an explicit `connect()` nor calls `getInputStream()`, because it doesn't have to. In code like this, the implementation of `FileURLConnection` internally in the implementation of `getLastModified()` and other similar APIs, does a `connect()`. As explained above, the implementation of `connect()` then creates and leaves around a `FileInputStream` after doing readability checks. In this above application code, the `InputStream` never reaches the application code nor does it closed, thus leading to the leak. The specification of `URLConnection` states: > The actual connection to the remote object is made, using the {@link #connect() connect} method. > The remote object becomes available. The header fields and the contents of the remote object can be accessed. > ... > Invoking the {@code close()} methods on the {@code InputStream} or {@code OutputStream} of an > {@code URLConnection} after a request may free network resources associated with this > instance, unless particular protocol specifications specify different behaviours > for it. It can be argued that it seems to expect that the application call `URLConnection.getInputStream()` and then close() it to close the resources, even in the case where it isn't interested in the `InputStream` or its contents. But, I think, it's a bit odd to be expecting applications to be doing that, if at all that's what is expected. So the change in this PR proposes to address the leak that can arise when the application never calls `URLConnection.getInputStream()`. The change in this PR, keeps the readability checks in the `connect()` method. However, the `FileInputStream` that is opened to do the readability check is closed before returning from the `connect()` method. That way, there is no `InputStream` lying around. When/if the application calls `URLConnection.getInputStream()` then the implementation in that method has been updated to construct and return the `FileInputStream`. This does mean that there's a change in behaviour for the following case (I consider it a corner case): - URLConnection is constructed for a "foo.txt" file which is readable - URLConnection.getLastModified() (or similar header related APIs) is invoked on that URLConnection. Internally that results in a connect() and file readability check and that succeeds. - Behind the scenes on the filesystem (or from some other part of the application), "foo.txt" file's permissions are modified to remove "read" permission. - URLConnection.getInputStream() is invoked on that previously constructed (and connected) URLConnection. Before the changes in this PR, the above scenario would result in the `URLConnection.getInputStream()` returning normally a `InputStream` instance (that was cached during the connect() call). The application would then be able to normally/successfully read content from that `InputStream`. With the proposed change in this PR, the `URLConnection.getInputStream()` call will throw a `FileNotFoundException`, when it attempts to construct the `FileInputStream` and noticing that the file doesn't have "read" permission. `URLConnection.getInputStream()` is specified to throw an `IOException`, so the exception (and its type) itself isn't a problem. It however is still a change in behaviour. Having said that, my opinion is that changing file permissions in between API calls on a `URLConnection` is a corner case and I think it might be OK if there is a change in behaviour here (along with a release note maybe), especially since I think the proposed change prevents a leak in a "normal" usage of t he `URLConnection` APIs in the application code (and also helps the internal implementation in `FileURLConnection` to have a more clearly demarcated lifetime for the `InputStream` instance). Additional care has been taken to make sure that no other change in behaviour is introduced. 2 new jtreg tests have been introduced. The `FileURLConnStreamLeakTest` is a regression test which reproduces the leak and verifies the fix - several test methods in this test will fail on Windows without the fix and will pass with the fix. The `GetInputStreamTest` is a new test which has been introduced to help improve the coverage of testing for the `InputStream` returned from the `FileURLConnection`. tier1, tier2 and tier3 tests pass with this change. ------------- Commit messages: - 8367561: fix inputstream leak - 8367561: introduce tests Changes: https://git.openjdk.org/jdk/pull/27633/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367561 Stats: 515 lines in 4 files changed: 483 ins; 11 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Sat Oct 4 16:35:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Oct 2025 16:35:08 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: missed pushing the change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/74439cc7..0703f7f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Sat Oct 4 16:35:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 4 Oct 2025 16:35:09 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v2] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 16:32:16 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > missed pushing the change src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 145: > 143: public String getHeaderField(String name) { > 144: initializeHeaders(); > 145: return super.getHeaderField(name); Several header related method implementations in this class have been updated to avoid the `super.XXXX()` calls. The `super.XXX()` implementation was calling `getInputStream()` and ignoring/not using the returned `InputStream`. That call to `getInputStream()` was a way to initiate a readability check and if the File wasn't readable then it would return a different result compared to when it was readable. The use of `getInputStream()` has been replaced by a call to `isReadable()` which does the same checks without leaving around a `InputStream` instance. Apart from that change, the rest of the code that resided in the `super.XXX()` implementation has been literally copy/pasted in these methods to avoid any kind of behavioural change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2404079257 From yuval.l at securithings.com Sun Oct 5 06:48:22 2025 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 5 Oct 2025 09:48:22 +0300 Subject: InetAddress.isReachable fix ETA In-Reply-To: References: <303E017C-91AD-43CE-911D-2D83D8BB91A7@me.com> <1c6fce1b-9a18-4a29-b913-3ea763b63fcf@oracle.com> Message-ID: Hello team, I had issues with subscribing to the net-dev, and now was able to resolve it, so now I am following up on this again. A bit of context to add to the query about the InetAddress.isReachable() issue I have posted. It seems my app underperforms when enabling InetAddress.isReachable() probing of multiple network devices (3-4K devices) with VT, and introducing a deliberate network traffic delay. With PT the issue seems significantly less severe On Tue, 30 Sept 2025 at 10:29, Yuval Lombard wrote: > Hey team, > > Following up on this, > > Did you have the chance to look at this? > > On Thu, 25 Sept 2025 at 09:09, Yuval Lombard > wrote: > >> Hey Team >> >> Is there an ETA for addressing the mentioned issue? >> >> https://bugs.openjdk.org/browse/JDK-8357160 >> >>> >>> On 20/09/2025 15:24, Yuval Lombard wrote: >>> > Hello team, >>> > >>> > Is there an estimated time/jdk release for fixing the InetAddress >>> > isReachable issue? >>> > >>> net-dev would be a better replace to discuss this. As I mentioned in >>> JDK-8357160 [1], I think it would be useful to know if it common for >>> deployments to have CAP_NET_RAW/equivalent or whether the TCP >>> implementation is more commonly used. If the TCP implementation were to >>> re-written in Java (not hard) then it would be "virtual thread friendly" >>> in the sense that waiting for SYN-ACK would release the carrier to do >>> other work. >>> >>> -Alan >>> >>> [1] https://bugs.openjdk.org/browse/JDK-8357160 >> >> >> >> -- >> >> Kind regards, >> >> *Yuval Lombard* >> >> *Staff Software Engineer* >> >> +972.50.548.0111 >> >> yuval.l at securithings.com >> >> [image: logo_black.png] >> > > > -- > > Kind regards, > > *Yuval Lombard* > > *Staff Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Staff Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From yuval.l at securithings.com Sun Oct 5 06:49:27 2025 From: yuval.l at securithings.com (Yuval Lombard) Date: Sun, 5 Oct 2025 09:49:27 +0300 Subject: InetAddress.isReachable fix ETA In-Reply-To: References: <303E017C-91AD-43CE-911D-2D83D8BB91A7@me.com> <1c6fce1b-9a18-4a29-b913-3ea763b63fcf@oracle.com> Message-ID: Forgot to mention I use jdk24 On Sun, 5 Oct 2025 at 09:48, Yuval Lombard wrote: > Hello team, > > I had issues with subscribing to the net-dev, and now was able to resolve > it, so now I am following up on this again. > > A bit of context to add to the query about the InetAddress.isReachable() > issue I have posted. > > It seems my app underperforms when enabling InetAddress.isReachable() > probing of multiple network devices (3-4K devices) with VT, and > introducing a deliberate network traffic delay. > With PT the issue seems significantly less severe > > On Tue, 30 Sept 2025 at 10:29, Yuval Lombard > wrote: > >> Hey team, >> >> Following up on this, >> >> Did you have the chance to look at this? >> >> On Thu, 25 Sept 2025 at 09:09, Yuval Lombard >> wrote: >> >>> Hey Team >>> >>> Is there an ETA for addressing the mentioned issue? >>> >>> https://bugs.openjdk.org/browse/JDK-8357160 >>> >>>> >>>> On 20/09/2025 15:24, Yuval Lombard wrote: >>>> > Hello team, >>>> > >>>> > Is there an estimated time/jdk release for fixing the InetAddress >>>> > isReachable issue? >>>> > >>>> net-dev would be a better replace to discuss this. As I mentioned in >>>> JDK-8357160 [1], I think it would be useful to know if it common for >>>> deployments to have CAP_NET_RAW/equivalent or whether the TCP >>>> implementation is more commonly used. If the TCP implementation were to >>>> re-written in Java (not hard) then it would be "virtual thread friendly" >>>> in the sense that waiting for SYN-ACK would release the carrier to do >>>> other work. >>>> >>>> -Alan >>>> >>>> [1] https://bugs.openjdk.org/browse/JDK-8357160 >>> >>> >>> >>> -- >>> >>> Kind regards, >>> >>> *Yuval Lombard* >>> >>> *Staff Software Engineer* >>> >>> +972.50.548.0111 >>> >>> yuval.l at securithings.com >>> >>> [image: logo_black.png] >>> >> >> >> -- >> >> Kind regards, >> >> *Yuval Lombard* >> >> *Staff Software Engineer* >> >> +972.50.548.0111 >> >> yuval.l at securithings.com >> >> [image: logo_black.png] >> > > > -- > > Kind regards, > > *Yuval Lombard* > > *Staff Software Engineer* > > +972.50.548.0111 > > yuval.l at securithings.com > > [image: logo_black.png] > -- Kind regards, *Yuval Lombard* *Staff Software Engineer* +972.50.548.0111 yuval.l at securithings.com [image: logo_black.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: logo_black.png Type: image/png Size: 99833 bytes Desc: not available URL: From mchhipa at openjdk.org Mon Oct 6 10:13:21 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 6 Oct 2025 10:13:21 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v3] In-Reply-To: References: Message-ID: > Update SimpleHttpServer class to use SimpleFileServer. Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Added jdk.test.lib.net.URIBuilder import. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27608/files - new: https://git.openjdk.org/jdk/pull/27608/files/64cad93a..53e6a665 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From dfuchs at openjdk.org Mon Oct 6 13:30:57 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 6 Oct 2025 13:30:57 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 10:13:21 GMT, Mahendra Chhipa wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Added jdk.test.lib.net.URIBuilder import. test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java line 104: > 102: httpserver.start(); > 103: remoteFilePath = "http:" + URIBuilder.newBuilder().host(httpserver.getAddress().getAddress()). > 104: port(httpserver.getAddress().getPort()).build().toString() + REMOTE_FILE_LOCATION; Suggestion: remoteFilePath = URIBuilder.newBuilder() .scheme("http") .host(httpserver.getAddress().getAddress()) .port(httpserver.getAddress().getPort()) .build().toString() + REMOTE_FILE_LOCATION; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27608#discussion_r2406311037 From michaelm at openjdk.org Mon Oct 6 14:14:36 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 6 Oct 2025 14:14:36 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 13:14:43 GMT, Volkan Yazici wrote: > Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. Looks good! ------------- PR Review: https://git.openjdk.org/jdk/pull/27623#pullrequestreview-3304950173 From mchhipa at openjdk.org Mon Oct 6 14:30:00 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 6 Oct 2025 14:30:00 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v4] In-Reply-To: References: Message-ID: > Update SimpleHttpServer class to use SimpleFileServer. Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: Used scheme() method to set protocol. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27608/files - new: https://git.openjdk.org/jdk/pull/27608/files/53e6a665..2aabe05c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27608&range=02-03 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27608/head:pull/27608 PR: https://git.openjdk.org/jdk/pull/27608 From dfuchs at openjdk.org Mon Oct 6 14:32:41 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 6 Oct 2025 14:32:41 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v2] In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 16:31:30 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> missed pushing the change > > src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 145: > >> 143: public String getHeaderField(String name) { >> 144: initializeHeaders(); >> 145: return super.getHeaderField(name); > > Several header related method implementations in this class have been updated to avoid the `super.XXXX()` calls. The `super.XXX()` implementation was calling `getInputStream()` and ignoring/not using the returned `InputStream`. That call to `getInputStream()` was a way to initiate a readability check and if the File wasn't readable then it would return a different result compared to when it was readable. The use of `getInputStream()` has been replaced by a call to `isReadable()` which does the same checks without leaving around a `InputStream` instance. Apart from that change, the rest of the code that resided in the `super.XXX()` implementation has been literally copy/pasted in these methods to avoid any kind of behavioural change. The code duplication is a bit distateful. Have you thought about introducing a package protected method in s.n.www.URLConnection e.g. ensureConnectionEstablished() that would by default call getInputStream()? Then you could possibly just override this method in the s.n.www.FileURLConnection subclass, instead of having to override all the methods that call getInputStream() just for the sake or replacing getInputStream() with isReadable()? I haven't experimented with what I'm suggesting here, and maybe you already considered and rejected it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2406673378 From dfuchs at openjdk.org Mon Oct 6 15:01:44 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 6 Oct 2025 15:01:44 GMT Subject: RFR: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer [v4] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 14:30:00 GMT, Mahendra Chhipa wrote: >> Update SimpleHttpServer class to use SimpleFileServer. > > Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision: > > Used scheme() method to set protocol. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27608#pullrequestreview-3305272280 From mchhipa at openjdk.org Mon Oct 6 15:29:45 2025 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Mon, 6 Oct 2025 15:29:45 GMT Subject: Integrated: 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer In-Reply-To: References: Message-ID: <85z9dtDbHuYDhentadql7zs5mWsic8Jzn4ehUI5iAso=.88ff8bda-8ed3-4991-89dc-2bad532f9ee4@github.com> On Thu, 2 Oct 2025 13:12:07 GMT, Mahendra Chhipa wrote: > Update SimpleHttpServer class to use SimpleFileServer. This pull request has now been integrated. Changeset: b6a4cfec Author: Mahendra Chhipa URL: https://git.openjdk.org/jdk/commit/b6a4cfecb731615b6ef70828ac10fae4b2264cdc Stats: 283 lines in 5 files changed: 32 ins; 230 del; 21 mod 8367114: Update jdk.test.lib.net.SimpleHttpServer to use SimpleFileServer Reviewed-by: dfuchs, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/27608 From duke at openjdk.org Mon Oct 6 16:15:55 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 6 Oct 2025 16:15:55 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes Message-ID: Now ExchangeImpl will default to having a separate attribute map for the request duration. ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-7105350 - Separate attributes for exchangeImpl Changes: https://git.openjdk.org/jdk/pull/27652/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=00 Issue: https://bugs.openjdk.org/browse/JDK-7105350 Stats: 19 lines in 1 file changed: 7 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From michal.gn at proton.me Mon Oct 6 17:22:47 2025 From: michal.gn at proton.me (=?utf-8?Q?Micha=C5=82_G=2E?=) Date: Mon, 06 Oct 2025 17:22:47 +0000 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl In-Reply-To: References: Message-ID: Hi Daniel, Thank you for your reply and the detailed explanation. I understand the reasoning behind using the client executor only for non-blocking tasks to streamline the exchange itself, and I agree it?s a good approach :) The main issue, which motivated me to write this email, is that it?s not clear on which executor the returned CompletableFuture executes. In our project, it?s critical to control which thread runs the operations. Currently, the flow looks like this: 1. The method is called from app-thread-1 2. The exchange is executed on exchange-1 3. Subsequent actions are executed on the ForkJoin pool While I can configure the first two executors, the HttpClient does not allow changing the third one, and there?s no way to override it. We discovered this while debugging our application: initially, we assumed callbacks would run on the HTTP executor, but later noticed they execute on the async pool, and were surprised there?s no way to change that, unlike in similar cases elsewhere in the platform. Additionally, since the CompletableFuture default executor is reused, on machines with one or two CPU cores it will fallback to ThreadPerTaskExecutor, causing a new system thread to be created for every HTTP request. This could be avoided if we were able to override the default executor, which would also improve performance on lower-end systems. For example, with the current implementation, if we configure a custom exchange executor and issue 100 HTTP requests without any reply handling on a 2-CPU system, we will end up creating 100 system threads that immediately terminate without doing meaningful work. Instead of introducing a new executor field, perhaps we could have an overloaded version of sendAsync that accepts an executor, similar to CompletableFuture?s API: CompletableFuture thenApplyAsync(Function fn, Executor executor) This would give developers clear control over where callbacks run, without complicating the client configuration, and would open the door for optimizations in performance-critical environments. It would not address the two other places where ASYNC_POOL is used (exception handling), but even partial control here would meaningfully improve the client?s flexibility and extensibility. I?d be more than happy to implement the change myself if anyone would like to sponsor it :) Best regards, Micha? > Hi Michal, > > >> Would such a change make sense, or is there a strong reason why we > must always fallback to the commonPool? > > > The HttpClient executor is used by the HttpClient for its > own purpose, which is to execute small (usually non-blocking) > asynchronous tasks. > In my todo list I have a task to add an `@implNote` or `@apiNote` >to better explain how the HttpClient uses the executor, and why > tasks submitted to the executor must always be executed. > > The idea was that no blocking code would run in that executor, > so it should be possible to configure the client with an > executor using a very small number of threads (or even an > executor that run tasks inline). > > In practice custom BodyPublishers/BodyHandlers/BodySubscribers > may be invoked while running in the executor, so it's hard to > guarantee that no blocking code would be invoked, but these > should adhere to the reactive stream specification, and thus, if > they adhere to the spec, do nothing blocking. > > Custom dependent actions that are added by the caller to > a CompletableFuture returned by sendAsync() have however no such > requirements, and nothing is there to prevent them from > doing blocking operations. Blocking in the HttpClient executor > would be bad, as it may lead to thread starvation and prevent > requests/responses from eventually completing. This is why we > forcefully ensure that such dependent actions are run in the > Fork Join Pool instead. > > That said, with VirtualThreads being now available in the > platform - I have been wondering whether we should just use > VirtualThreads internally. There are still a few limitations > with VirtualThreads pertaining to class loading and static > initializers, so we haven't switched to that yet, but may > do so in the future. If we eventually do, then maybe the > HttpClient executor could be repurposed to execute (only) > dependent actions. > I am not sure we would like to configure the HttpClient with > yet another executor however. > How big an issue is this? > best regards, > -- daniel > This belongs to the net-dev mailing list, which I CC'ed. > > On Wed, Oct 1, 2025 at 10:56?AM Micha? G. michal.gn at proton.me wrote: > > > Hi all, > > > > I recently ran into an issue with HttpClientImpl where I wanted to handle the reply right after calling sendAsync. What surprised me is that the returned CompletableFuture already runs on the commonPool, instead of using the executor I provided to the HttpClient. > > > > Looking into the implementation, I noticed this piece of code: > > > > // makes sure that any dependent actions happen in the CF default > > // executor. This is only needed for sendAsync(...), when > > // exchangeExecutor is non-null. > > if (exchangeExecutor != null) { > > res = res.whenCompleteAsync((r, t) -> { /* do nothing */}, ASYNC_POOL); > > } > > > > I understand that this exchangeExecutor is meant to cover the request/response exchange itself, not necessarily the CompletableFuture chaining. But the fact that we always force the returned future back onto the commonPool, without any way to change this, feels quite limiting. > > > > In environments where the commonPool is already heavily loaded, this can easily introduce performance issues or unpredictable behavior. And since > > > > private static final Executor ASYNC_POOL = new CompletableFuture().defaultExecutor(); > > > > is fixed and cannot be replaced, users don?t have any way around it. For comparison, the default executor for CompletableFuture.supplyAsync or for parallelStream() is also the commonPool, but in those cases it?s easy to override it with a custom executor. It would be nice if HttpClientImpl offered the same flexibility. > > > > This is why I?d like to propose a change: when creating an HttpClientImpl, it should be possible to specify not only the exchange executor, but also the executor used for the returned CompletableFuture > > > > This would be backwards compatible (just an additional optional builder parameter), and it could bring several benefits: > > > > reduced context switching for clients that care about which thread executes response handling, > > > > more predictable performance in environments where commonPool is shared with other workloads, > > > > easier integration with frameworks that already manage their own executors, > > > > clearer control and observability over where callbacks are executed. > > > > Would such a change make sense, or is there a strong reason why we must always fallback to the commonPool? From alan.bateman at oracle.com Mon Oct 6 18:12:25 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 6 Oct 2025 19:12:25 +0100 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl In-Reply-To: References: Message-ID: On 06/10/2025 18:22, Micha? G. wrote: > : > > Additionally, since the CompletableFuture default executor is reused, on machines with one or two CPU cores it will fallback to ThreadPerTaskExecutor, causing a new system thread to be created for every HTTP request. Note that this changed in JDK 25 so that the async methods without an explicit Executor will submit to the common pool. -Alan. From michal.gn at proton.me Mon Oct 6 18:56:51 2025 From: michal.gn at proton.me (=?utf-8?Q?Micha=C5=82_G=2E?=) Date: Mon, 06 Oct 2025 18:56:51 +0000 Subject: Proposal: Custom executor for CompletableFuture in HttpClientImpl In-Reply-To: References: Message-ID: Thanks for the insight, i wasn?t aware of this nice improvement :) i still think the change in HttpClient could be useful, as it still hardcodes the commonPool and doesn?t allow any customization > > On 06/10/2025 18:22, Micha? G. wrote: > > > : > > > > Additionally, since the CompletableFuture default executor is reused, on machines with one or two CPU cores it will fallback to ThreadPerTaskExecutor, causing a new system thread to be created for every HTTP request. > > Note that this changed in JDK 25 so that the async methods without an > explicit Executor will submit to the common pool. > > -Alan. From jpai at openjdk.org Tue Oct 7 08:07:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Oct 2025 08:07:39 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Daniel's suggestion - don't repeat/copy code from super() - merge latest from master branch - missed pushing the change - 8367561: fix inputstream leak - 8367561: introduce tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/0703f7f5..92382cd6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=01-02 Stats: 2666 lines in 82 files changed: 1774 ins; 679 del; 213 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Tue Oct 7 08:11:12 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 7 Oct 2025 08:11:12 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 14:30:07 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 145: >> >>> 143: public String getHeaderField(String name) { >>> 144: initializeHeaders(); >>> 145: return super.getHeaderField(name); >> >> Several header related method implementations in this class have been updated to avoid the `super.XXXX()` calls. The `super.XXX()` implementation was calling `getInputStream()` and ignoring/not using the returned `InputStream`. That call to `getInputStream()` was a way to initiate a readability check and if the File wasn't readable then it would return a different result compared to when it was readable. The use of `getInputStream()` has been replaced by a call to `isReadable()` which does the same checks without leaving around a `InputStream` instance. Apart from that change, the rest of the code that resided in the `super.XXX()` implementation has been literally copy/pasted in these methods to avoid any kind of behavioural change. > > The code duplication is a bit distateful. Have you thought about introducing a package protected method in s.n.www.URLConnection e.g. ensureConnectionEstablished() that would by default call getInputStream()? > Then you could possibly just override this method in the s.n.www.FileURLConnection subclass, instead of having to override all the methods that call getInputStream() just for the sake or replacing getInputStream() with isReadable()? > > I haven't experimented with what I'm suggesting here, and maybe you already considered and rejected it. Hello Daniel, when I started on this fix, I intended to keep the changes only to the `sun.net.www.protocol.file.FileURLConnection` to reduce the chances of unforeseen problems. So I hadn't given it a thought to update the `sun.net.www.URLConnection` class. But what you suggest here is much more cleaner and at the same time allows us to fix this issue in `FileURLConnection`. So I've updated this PR to follow your suggestion. I decided to name the new (internal) method as `ensureCanServeHeaders()` to be more precise about what its role is. I can rename it to something else, if necessary. I verified that the tests pass and the original leak is addressed even after these latest changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2409775501 From vyazici at openjdk.org Tue Oct 7 08:15:48 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 7 Oct 2025 08:15:48 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 17:12:49 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/net/URL.java line 1402: >> >>> 1400: throw new Error("Circular loading of URL stream handler providers detected"); >>> 1401: } >>> 1402: return ScopedValue.where(IN_LOOKUP, true).call(() -> { >> >> We should never reach here if the VM is not booted, or if the protocol is `file:` or `jrt:` - so it may be safe to use a lambda. The alternative would be to use an anonymous class and create a `new Runnable() { ... }` but it's probably not needed. > > The changes to URL look okay but good to run any startup benchmarks to check startup performance. Run benchmarks comparing 2e783963d21 (of `master`) with 97d012eac25 on several platforms, and did not notice any noteworthy regressions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27623#discussion_r2409781269 From vyazici at openjdk.org Tue Oct 7 08:15:50 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 7 Oct 2025 08:15:50 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup [v2] In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 17:19:44 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Match indentation styles > > test/jdk/java/net/spi/URLStreamHandlerProvider/Basic.java line 143: > >> 141: TEST_SRC.resolve("circular.provider.template"), >> 142: sysProps); >> 143: } > > I assume you've re-format the changes to Basic.java to be consistent with this existing code in the test (looks a bit strange on first sighting to see a completely different style being introduced). Matched styles in 23abe110629. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27623#discussion_r2409786091 From vyazici at openjdk.org Tue Oct 7 08:15:46 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 7 Oct 2025 08:15:46 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup [v2] In-Reply-To: References: Message-ID: > Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Match indentation styles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27623/files - new: https://git.openjdk.org/jdk/pull/27623/files/97d012ea..23abe110 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27623&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27623&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27623.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27623/head:pull/27623 PR: https://git.openjdk.org/jdk/pull/27623 From michaelm at openjdk.org Tue Oct 7 09:28:25 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 7 Oct 2025 09:28:25 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes In-Reply-To: References: Message-ID: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> On Mon, 6 Oct 2025 16:09:40 GMT, Josiah Noel wrote: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Probably need a test for this as well src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 65: > 63: private static final boolean perExchangeAttributes = > 64: !System.getProperty("jdk.httpserver.attributes", "") > 65: .equals("context"); The property will have to be documented somewhere such as the jdk.httpserver module-info. But, I'm wondering if fairly obscure properties like this might be better off "buried" in the net.properties config file. I think there's a case for putting all such "compatibility" flags somewhere out of the way like that. If we were to do that, you would need to access the property using `sun.net.NetProperties`. Any other views on this? src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 374: > 372: throw new NullPointerException("null name parameter"); > 373: } > 374: return attributes.get(name); Consider replacing this with `Objects.requireNonNull` src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 379: > 377: public void setAttribute (String name, Object value) { > 378: if (name == null) { > 379: throw new NullPointerException("null name parameter"); As above ------------- PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3309209288 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2409980226 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2409985587 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2409986147 From alanb at openjdk.org Tue Oct 7 10:15:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 7 Oct 2025 10:15:51 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 08:15:46 GMT, Volkan Yazici wrote: >> Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Match indentation styles Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27623#pullrequestreview-3309407796 From myankelevich at openjdk.org Tue Oct 7 10:18:18 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 7 Oct 2025 10:18:18 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 Message-ID: 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). ------------- Commit messages: - JDK-8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 Changes: https://git.openjdk.org/jdk/pull/27670/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368625 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27670/head:pull/27670 PR: https://git.openjdk.org/jdk/pull/27670 From vyazici at openjdk.org Tue Oct 7 11:40:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 7 Oct 2025 11:40:52 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 08:07:39 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Daniel's suggestion - don't repeat/copy code from super() > - merge latest from master branch > - missed pushing the change > - 8367561: fix inputstream leak > - 8367561: introduce tests src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 125: > 123: } else { > 124: try (var _ = new FileInputStream(file.getPath())) { > 125: } *Nit:* You can consider shortening this to `new FileInputStream(file.getPath()).close()`. src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 258: > 256: is = new BufferedInputStream(new FileInputStream(file.getPath())); > 257: } > 258: return is; 90% of this work ? i.e., getting the file listing ? is already done in `connect()`. `getInputStream()` only concatenates `directoryListing`. Moving this last 10% logic to `connect()`, making it populate a private Supplier inputStreamSupplier; field, can simplify the code. Have you considered this route? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2409922581 PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2410326632 From dfuchs at openjdk.org Tue Oct 7 14:16:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 7 Oct 2025 14:16:14 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 08:15:46 GMT, Volkan Yazici wrote: >> Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Match indentation styles Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27623#pullrequestreview-3310333974 From dfuchs at openjdk.org Tue Oct 7 14:45:36 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 7 Oct 2025 14:45:36 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 11:36:16 GMT, Volkan Yazici wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Daniel's suggestion - don't repeat/copy code from super() >> - merge latest from master branch >> - missed pushing the change >> - 8367561: fix inputstream leak >> - 8367561: introduce tests > > src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 258: > >> 256: is = new BufferedInputStream(new FileInputStream(file.getPath())); >> 257: } >> 258: return is; > > 90% of this work ? i.e., getting the file listing ? is already done in `connect()`. `getInputStream()` only concatenates `directoryListing`. Moving this last 10% logic to `connect()`, making it populate a > > private Supplier inputStreamSupplier; > > field, can simplify the code. Have you considered this route? I'm guessing this is going to be a candidate for backporting - so let's keep the changes minimum. I'd rather keep that code in getInputStream() as it conceptually belong there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2410873623 From dfuchs at openjdk.org Tue Oct 7 14:45:33 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 7 Oct 2025 14:45:33 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 08:07:39 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Daniel's suggestion - don't repeat/copy code from super() > - merge latest from master branch > - missed pushing the change > - 8367561: fix inputstream leak > - 8367561: introduce tests The new changes look great. test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 73: > 71: "unexpected URLConnection type"); > 72: final var _ = conn.getContentEncoding(); > 73: Files.delete(this.testFile); // must not fail You should probably make sure that the connection is not garbage collected before deleting the file. There are very little chances that it consistently would - but you never know. ------------- PR Review: https://git.openjdk.org/jdk/pull/27633#pullrequestreview-3310448291 PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2410887145 From msheppar at openjdk.org Tue Oct 7 15:53:18 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 7 Oct 2025 15:53:18 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 10:11:22 GMT, Mikhail Yankelevich 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). The extending of the stop duration may not have the desired effect of eliminating what appears to be a race condition in the test One of the recorded failures is for the temporal condition // The shutdown should take at least as long as the exchange duration if (elapsed < exchangeDuration.toNanos()) { fail("HttpServer.stop terminated before exchange completed"); } This is a somewhat dubious constraint and can?t always be met The test assumes that the participating threads are all actively executing simultaneously, which may not be true They may be scheduled to run rather than actually running. Restating the objective of the test Objective: to ensure that the stop request is not processed while there are extant exchanges Potential race scenario: Server started creates exchange which waits for a signal to complete Exchange completion thread starts waits for 1 seconds before it can signal exchange to compete ? the complete signal will be thus invoked sometime after 1 second depending on OS thread scheduling Main thread continues and invokes a stop which has a max wait time of 5 seconds for extant exchanges to complete ? so max completion time of stop is 5 seconds ++ i.e. could be slightly longer than 5 seconds again subject to OS scheduling Temporal condition imposed by test // The shutdown should take at least as long as the exchange duration if (elapsed < exchangeDuration.toNanos()) { fail("HttpServer.stop terminated before exchange completed"); } // The delay should not have expired if (elapsed >= delayDuration.toNanos()) { fail("HttpServer.stop terminated after delay expired"); } 1. States elapsed time of stop should be less than the duration of the exchange exchangeDuration. BUT exchangeDuration is not the duration of the exchange completion. Rather, it is the time delay before the exchange thread is signalled to complete. The actual completion of the exchange may be sometime later, again depending on OS thread scheduling. Second condition is that the elapsed time of the stop should be less than or equal to the stop delay. BUT if the full timeout for the stop expires as per server.stop will wait a max of N (5) seconds before terminating as per try { // waiting for the duration of the delay, unless released before finishedLatch.await(delay, TimeUnit.SECONDS); } catch (InterruptedException e) { logger.log(Level.TRACE, "Error in awaiting the delay"); } finally { Then this infers that the extant exchanges have taken longer than the expected or allowed time. This in turn infers that the exchange is still executing or waiting to execute at the time of the stop request. All in all the temporal conditions are not exact and they are subject to variability depending on the scheduling of threads by the OS. BUT extending of the delayDuration doesn?t necessarily impact the first condition, which has failed, because the elapsed time may be less than the exchange duration due to OS scheduling ------------- PR Comment: https://git.openjdk.org/jdk/pull/27670#issuecomment-3377522093 From vyazici at openjdk.org Tue Oct 7 15:57:24 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 7 Oct 2025 15:57:24 GMT Subject: RFR: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup [v2] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 10:13:11 GMT, Alan Bateman wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Match indentation styles > > Marked as reviewed by alanb (Reviewer). @AlanBateman, @dfuch, @Michael-Mc-Mahon, thank you very much for kind reviews. Using 23abe110629, `tier1,2` passes on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27623#issuecomment-3377536918 From vyazici at openjdk.org Tue Oct 7 16:00:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 7 Oct 2025 16:00:43 GMT Subject: Integrated: 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup In-Reply-To: References: Message-ID: On Fri, 3 Oct 2025 13:14:43 GMT, Volkan Yazici wrote: > Replace `ThreadTracker` usage in `java.net.URL` with `ScopedValue` and add a test. This pull request has now been integrated. Changeset: eb835e05 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/eb835e05f9cf8a65d804b733b382ecfba5b12907 Stats: 83 lines in 3 files changed: 64 ins; 14 del; 5 mod 8366040: Change URL.lookupViaProviders to use ScopedValue to detect recursive lookup Reviewed-by: alanb, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27623 From duke at openjdk.org Tue Oct 7 16:10:20 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 7 Oct 2025 16:10:20 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v2] In-Reply-To: References: Message-ID: <-e90OA6HNgU5c0OFOWoEcx27cGt1ZpZWPMh7xJu6KoM=.704e1993-afd7-4bb2-8a4a-0003b557bf20@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: require non null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/a1f2873c..62937b8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=00-01 Stats: 9 lines in 1 file changed: 0 ins; 5 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Wed Oct 8 02:33:04 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 02:33:04 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v2] In-Reply-To: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> References: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> Message-ID: On Tue, 7 Oct 2025 09:22:39 GMT, Michael McMahon wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> require non null > > src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 65: > >> 63: private static final boolean perExchangeAttributes = >> 64: !System.getProperty("jdk.httpserver.attributes", "") >> 65: .equals("context"); > > The property will have to be documented somewhere such as the jdk.httpserver module-info. But, I'm wondering if fairly obscure properties like this might be better off "buried" in the net.properties config file. I think there's a case for putting all such "compatibility" flags somewhere out of the way like that. If we were to do that, you would need to access the property using `sun.net.NetProperties`. > > Any other views on this? I can switch to `sun.net.NetProperties` if you so desire. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2412350550 From djelinski at openjdk.org Wed Oct 8 09:46:56 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 8 Oct 2025 09:46:56 GMT Subject: RFR: 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds Message-ID: Remove connectTimeout setting from all tests that set it without a good reason. It causes occasional test failures, especially on machines running tests with artificially inflated level of parallelism. The tests continue to pass. ------------- Commit messages: - Remove unnecessary connectTimeout setting Changes: https://git.openjdk.org/jdk/pull/27686/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27686&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369291 Stats: 7 lines in 5 files changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27686.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27686/head:pull/27686 PR: https://git.openjdk.org/jdk/pull/27686 From jpai at openjdk.org Wed Oct 8 10:10:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Oct 2025 10:10:55 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v4] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Volkan's review - merge latest from master branch - Daniel's suggestion - don't repeat/copy code from super() - merge latest from master branch - missed pushing the change - 8367561: fix inputstream leak - 8367561: introduce tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/92382cd6..799e41b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=02-03 Stats: 3950 lines in 73 files changed: 3203 ins; 359 del; 388 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Wed Oct 8 10:10:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Oct 2025 10:10:58 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 09:00:59 GMT, Volkan Yazici wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Daniel's suggestion - don't repeat/copy code from super() >> - merge latest from master branch >> - missed pushing the change >> - 8367561: fix inputstream leak >> - 8367561: introduce tests > > src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 125: > >> 123: } else { >> 124: try (var _ = new FileInputStream(file.getPath())) { >> 125: } > > *Nit:* You can consider shortening this to `new FileInputStream(file.getPath()).close()`. Done, I've updated the PR to use this construct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2413308770 From michaelm at openjdk.org Wed Oct 8 10:14:17 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 8 Oct 2025 10:14:17 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v2] In-Reply-To: References: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> Message-ID: On Wed, 8 Oct 2025 02:29:54 GMT, Josiah Noel wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 65: >> >>> 63: private static final boolean perExchangeAttributes = >>> 64: !System.getProperty("jdk.httpserver.attributes", "") >>> 65: .equals("context"); >> >> The property will have to be documented somewhere such as the jdk.httpserver module-info. But, I'm wondering if fairly obscure properties like this might be better off "buried" in the net.properties config file. I think there's a case for putting all such "compatibility" flags somewhere out of the way like that. If we were to do that, you would need to access the property using `sun.net.NetProperties`. >> >> Any other views on this? > > I can switch to `sun.net.NetProperties` if you so desire. Yeah, I think we should put the property in `net.properties` something like this: # Prior to JDK 26, the HttpExchange attribute map was shared with the enclosing HttpContext. # Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must # be accessed by calling getHttpContext().getAttributes(). Uncomment this property to # restore the pre JDK 26 behavior. # # jdk.httpserver.attributes=context Then I think we should add a sentence at the end of the jdk.httpserver module-info to say that additional system/networking properties may be defined in `net.properties` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2413328557 From jpai at openjdk.org Wed Oct 8 10:25:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Oct 2025 10:25:06 GMT Subject: RFR: 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds In-Reply-To: References: Message-ID: <9qgyWvoEZIGylB3uglmUX0IdbVqoKTRr40T_S7GU4Yw=.9b1fd694-1941-4368-9900-2687acbed08c@github.com> On Wed, 8 Oct 2025 09:30:37 GMT, Daniel Jeli?ski wrote: > Remove connectTimeout setting from all tests that set it without a good reason. It causes occasional test failures, especially on machines running tests with artificially inflated level of parallelism. > > The tests continue to pass. This looks reasonable to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27686#pullrequestreview-3314144751 From jpai at openjdk.org Wed Oct 8 10:26:24 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Oct 2025 10:26:24 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v5] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Daniel's suggestion - add reachability fence ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/799e41b0..0f23e390 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=03-04 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Wed Oct 8 10:26:27 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Oct 2025 10:26:27 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 14:41:51 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Daniel's suggestion - don't repeat/copy code from super() >> - merge latest from master branch >> - missed pushing the change >> - 8367561: fix inputstream leak >> - 8367561: introduce tests > > test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 73: > >> 71: "unexpected URLConnection type"); >> 72: final var _ = conn.getContentEncoding(); >> 73: Files.delete(this.testFile); // must not fail > > You should probably make sure that the connection is not garbage collected before deleting the file. > There are very little chances that it consistently would - but you never know. I had a look at the FileURLConnection hierarchy and the FileInputStream class. None of those have a finalize() nor any cleaners. Which would mean that even if these objects were garbage collected, the underlying file descriptor (used by FileInputStream) would still be open. Having said that, I haven't checked older releases (to which this might get backported). So I've added a `ReachabilityFence` for the `URLConnection` instance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2413373819 From dfuchs at openjdk.org Wed Oct 8 12:47:40 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 12:47:40 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 15:50:30 GMT, Mark Sheppard 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). > > The extending of the stop duration may not have the desired effect of eliminating what appears to be a race condition in the test > > One of the recorded failures is for the temporal condition > > // The shutdown should take at least as long as the exchange duration > if (elapsed < exchangeDuration.toNanos()) { > fail("HttpServer.stop terminated before exchange completed"); > } > > This is a somewhat dubious constraint and can?t always be met > > The test assumes that the participating threads are all actively executing simultaneously, which may not be true > They may be scheduled to run rather than actually running. > > Restating the objective of the test > Objective: to ensure that the stop request is not processed while there are extant exchanges > > Potential race scenario: > > Server started creates exchange which waits for a signal to complete > > Exchange completion thread starts waits for 1 seconds before it can signal exchange to compete ? the complete signal will be thus invoked sometime after 1 second depending on OS thread scheduling > > Main thread continues and invokes a stop which has a max wait time of 5 seconds for extant exchanges to complete ? so max completion time of stop is 5 seconds ++ i.e. could be slightly longer than 5 seconds again subject to OS scheduling > > Temporal condition imposed by test > > // The shutdown should take at least as long as the exchange duration > if (elapsed < exchangeDuration.toNanos()) { > fail("HttpServer.stop terminated before exchange completed"); > } > > // The delay should not have expired > if (elapsed >= delayDuration.toNanos()) { > fail("HttpServer.stop terminated after delay expired"); > } > > 1. States elapsed time of stop should be less than the duration of the exchange exchangeDuration. BUT exchangeDuration is not the > duration of the exchange completion. Rather, it is the time delay before the exchange thread is signalled to complete. > The actual completion of the exchange may be sometime later, again depending on OS thread scheduling. > > Second condition is that the elapsed time of the stop should be less than or equal to the stop delay. BUT if the full timeout for the > stop expires as per > > server.stop will wait a max of N (5) seconds before terminating as per > > try { > // waiting for the duration of the delay, unless released before > finishedLatch.await(delay, TimeUnit.SECONDS); > > } catch (InterruptedExceptio... I believe Mark is right - there is an issue with the timing logic in this method. The virtual thread that sleeps before calling complete.countDown() may finish sleeping and call countDown() before server.stop() is called. Good analysis @msheppar ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27670#issuecomment-3381344845 From dfuchs at openjdk.org Wed Oct 8 13:04:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 13:04:58 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v2] In-Reply-To: <-e90OA6HNgU5c0OFOWoEcx27cGt1ZpZWPMh7xJu6KoM=.704e1993-afd7-4bb2-8a4a-0003b557bf20@github.com> References: <-e90OA6HNgU5c0OFOWoEcx27cGt1ZpZWPMh7xJu6KoM=.704e1993-afd7-4bb2-8a4a-0003b557bf20@github.com> Message-ID: On Tue, 7 Oct 2025 16:10:20 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > require non null I agree with @Michael-Mc-Mahon that we will need a test to verify both old (with property set) and new behavior. Also this change will require a CSR and release notes. Otherwise the proposed solution looks good. I believe it meets what a user reading the documentation would expect: get/set attributes on context get/set attributes for the whole context and may be observed by all exchanges that operate on this context. get/set attribute on the exchange get/set attributes whose scope is limited to that particular exchange. This was a long standing issue and I'm happy to see it fixed. Thanks for driving that @SentryMan and @Michael-Mc-Mahon ! ------------- PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3314681395 From dfuchs at openjdk.org Wed Oct 8 13:04:59 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 13:04:59 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v2] In-Reply-To: References: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> Message-ID: On Wed, 8 Oct 2025 10:09:16 GMT, Michael McMahon wrote: >> I can switch to `sun.net.NetProperties` if you so desire. > > Yeah, I think we should put the property in `net.properties` something like this: > > > # Prior to JDK 26, the HttpExchange attribute map was shared with the enclosing HttpContext. > # Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must > # be accessed by calling getHttpContext().getAttributes(). Uncomment this property to > # restore the pre JDK 26 behavior. > # > # jdk.httpserver.attributes=context > > Then I think we should add a sentence at the end of the jdk.httpserver module-info to say that additional > system/networking properties may be defined in `net.properties` That proposal sounds good to me. Documenting the compatibiity in net.properties makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2413763085 From dfuchs at openjdk.org Wed Oct 8 13:16:39 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 13:16:39 GMT Subject: RFR: 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 09:30:37 GMT, Daniel Jeli?ski wrote: > Remove connectTimeout setting from all tests that set it without a good reason. It causes occasional test failures, especially on machines running tests with artificially inflated level of parallelism. > > The tests continue to pass. Looks good. Removing that unneeded timeout from the other tests makes sense too. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27686#pullrequestreview-3314765223 From dfuchs at openjdk.org Wed Oct 8 13:22:31 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 13:22:31 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 10:20:59 GMT, Jaikiran Pai wrote: >> test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 73: >> >>> 71: "unexpected URLConnection type"); >>> 72: final var _ = conn.getContentEncoding(); >>> 73: Files.delete(this.testFile); // must not fail >> >> You should probably make sure that the connection is not garbage collected before deleting the file. >> There are very little chances that it consistently would - but you never know. > > I had a look at the FileURLConnection hierarchy and the FileInputStream class. None of those have a finalize() nor any cleaners. Which would mean that even if these objects were garbage collected, the underlying file descriptor (used by FileInputStream) would still be open. Having said that, I haven't checked older releases (to which this might get backported). So I've added a `ReachabilityFence` for the `URLConnection` instance. If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor: https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2413840582 From dfuchs at openjdk.org Wed Oct 8 13:25:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 13:25:58 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 13:19:52 GMT, Daniel Fuchs wrote: >> I had a look at the FileURLConnection hierarchy and the FileInputStream class. None of those have a finalize() nor any cleaners. Which would mean that even if these objects were garbage collected, the underlying file descriptor (used by FileInputStream) would still be open. Having said that, I haven't checked older releases (to which this might get backported). So I've added a `ReachabilityFence` for the `URLConnection` instance. > > If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor: > https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140 Thanks for adding the reachability fence. An other possibility would have been to temporarily stash `conn` in a static field. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2413852147 From jpai at openjdk.org Wed Oct 8 13:32:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 8 Oct 2025 13:32:15 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 13:23:39 GMT, Daniel Fuchs wrote: >> If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor: >> https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140 > > Thanks for adding the reachability fence. An other possibility would have been to temporarily stash `conn` in a static field. > If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor: > > https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140 You are right indeed - I have stared at that constructor code for several minutes but hadn't spotted this. I had additionally done a text search for "cleaner" in that class and only found their references in the javadoc text. Thank you for catching this. GC could indeed have played a role here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2413869709 From dfuchs at openjdk.org Wed Oct 8 13:56:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 13:56:14 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v5] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 10:26:24 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's suggestion - add reachability fence Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27633#pullrequestreview-3314936881 From duke at openjdk.org Wed Oct 8 14:16:00 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:16:00 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v3] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: net property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/62937b8b..9d1d35b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=01-02 Stats: 14 lines in 4 files changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Wed Oct 8 14:45:59 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:45:59 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: References: Message-ID: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update module-info.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/9d1d35b4..434d2a99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Wed Oct 8 14:54:30 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:54:30 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: Message-ID: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update module-info.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/434d2a99..7711d93c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From dfuchs at openjdk.org Wed Oct 8 14:54:33 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 14:54:33 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> References: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> Message-ID: On Wed, 8 Oct 2025 14:45:59 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java src/jdk.httpserver/share/classes/module-info.java line 104: > 102: * > 103: * > 104: * Additional system/networking properties may be defined in net.properties I'd suggest the following to match other places were net.properties is mentioned in the API doc. Suggestion: * Additional system/networking properties may be defined in the {@code conf/net.properties} configuration file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414119090 From duke at openjdk.org Wed Oct 8 14:55:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 14:55:02 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> References: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> Message-ID: On Wed, 8 Oct 2025 14:45:59 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java > @SentryMan please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-7105350](https://bugs.openjdk.org/browse/JDK-7105350) with the correct fix version. How should I go about creating a CSR? The FAQ on this page says that I need JIRA access (I don't have that) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3381946202 From dfuchs at openjdk.org Wed Oct 8 14:58:08 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 14:58:08 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v4] In-Reply-To: References: <10DEK65F7O7il0Fevpke19vEOJM4hlTzOuJeqLsj6OY=.ec69af10-cc17-4b62-bd44-efcc838e194e@github.com> Message-ID: On Wed, 8 Oct 2025 14:52:59 GMT, Josiah Noel wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update module-info.java > >> @SentryMan please create a [CSR](https://wiki.openjdk.org/display/csr/Main) request for issue [JDK-7105350](https://bugs.openjdk.org/browse/JDK-7105350) with the correct fix version. > > How should I go about creating a CSR? The FAQ on this page says that I need JIRA access (I don't have that) @SentryMan note: WRT to creating a CSR your sponsor will handle that if you do not have a JBS account. Let's wait until this PR has been approved and everyone is happy with the API doc / behaviours changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3381959526 From alanb at openjdk.org Wed Oct 8 15:04:17 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 8 Oct 2025 15:04:17 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> Message-ID: On Wed, 8 Oct 2025 14:54:30 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java src/java.base/share/classes/module-info.java line 282: > 280: java.net.http, > 281: jdk.naming.dns, > 282: jdk.httpserver; It would be good if we could avoid giving the jdk.httpserver module access to the sun.net.* package. @dfuch @Michael-Mc-Mahon Are you sure that net.properties is the right place for this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414176619 From dfuchs at openjdk.org Wed Oct 8 15:17:17 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 15:17:17 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain Message-ID: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. ------------- Commit messages: - 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain Changes: https://git.openjdk.org/jdk/pull/27694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27694&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369313 Stats: 40 lines in 1 file changed: 26 ins; 11 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27694/head:pull/27694 PR: https://git.openjdk.org/jdk/pull/27694 From dfuchs at openjdk.org Wed Oct 8 15:15:39 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 15:15:39 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> Message-ID: On Wed, 8 Oct 2025 15:02:02 GMT, Alan Bateman wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update module-info.java > > src/java.base/share/classes/module-info.java line 282: > >> 280: java.net.http, >> 281: jdk.naming.dns, >> 282: jdk.httpserver; > > It would be good if we could avoid giving the jdk.httpserver module access to the sun.net.* package. > > @dfuch @Michael-Mc-Mahon Are you sure that net.properties is the right place for this? @AlanBateman I hadn't realised that the HttpServer didn't already have access to `sun.net.*` - and I agree that it would be better if we did not add such an access. That said - the new property is a compatibility property - and documenting in module-info seemed a bit too much - so out of the way in `net.properties` seemed like an appealing place to add it. Another possibility could be to document it only in the release notes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414209436 From fandreuzzi at openjdk.org Wed Oct 8 15:29:15 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 8 Oct 2025 15:29:15 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> Message-ID: <0jZMqGG2qzL030Gir2IMTwdLaShMvdyo0b33rOGZBY0=.a4acc603-0f48-4ec6-bf63-e7ad5ac8afec@github.com> On Wed, 8 Oct 2025 15:07:17 GMT, Daniel Fuchs wrote: > The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. > > In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. test/jdk/java/net/httpclient/TimeoutBasic.java line 153: > 151: } > 152: } > 153: assert x == null; Is there a way to exit the loop without `x` being `null`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27694#discussion_r2414255528 From dfuchs at openjdk.org Wed Oct 8 15:37:22 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 15:37:22 GMT Subject: RFR: 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently Message-ID: The test expects that the first request will go to the HTTP/2 server and the next will go to HTTP/3. But since the default config is to use Http3DiscoveryMode.ANY it can manage to send the first request with HTTP/3 instead. Requests should be explicitly configured with Http3DiscoveryMode.ALT_SVC. ------------- Commit messages: - 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently Changes: https://git.openjdk.org/jdk/pull/27696/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27696&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369434 Stats: 21 lines in 1 file changed: 12 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27696/head:pull/27696 PR: https://git.openjdk.org/jdk/pull/27696 From vyazici at openjdk.org Wed Oct 8 15:57:22 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 8 Oct 2025 15:57:22 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 13:29:19 GMT, Jaikiran Pai wrote: >> Thanks for adding the reachability fence. An other possibility would have been to temporarily stash `conn` in a static field. > >> If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor: >> >> https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140 > > > You are right indeed - I have stared at that constructor code for several minutes but hadn't spotted this. I had additionally done a text search for "cleaner" in that class and only found their references in the javadoc text. Thank you for catching this. GC could indeed have played a role here. This is a very subtle detail, shall we document the rationale for `Reference.reachabilityFence(conn)`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2414338877 From vyazici at openjdk.org Wed Oct 8 16:05:23 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 8 Oct 2025 16:05:23 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v5] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 10:26:24 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's suggestion - add reachability fence test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 1: > 1: /* Converting this entire class to a single `@ParameterizedTest` method (i.e., no instance field, no `@{Before,After}Each`) can avoid significant duplication. @ParameterizedTest("connTesters") void test(Consumer connTester) { Path file = Files.createTempFile(Path.of("."), "8367561-", ".txt"); try { Files.writeString(file, String.valueOf(System.currentTimeMillis())); URLConnection conn = file.toUri().toURL().openConnection(); assertNotNull(conn, "URLConnection for " + file + " is null"); assertEquals(FILE_URLCONNECTION_CLASSNAME, conn.getClass().getName(), "unexpected URLConnection type"); connTester.accept(conn); Reference.reachabilityFence(conn); } finally { Files.deleteIfExists(file); } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2414359823 From dfuchs at openjdk.org Wed Oct 8 16:05:22 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 16:05:22 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: <0jZMqGG2qzL030Gir2IMTwdLaShMvdyo0b33rOGZBY0=.a4acc603-0f48-4ec6-bf63-e7ad5ac8afec@github.com> References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> <0jZMqGG2qzL030Gir2IMTwdLaShMvdyo0b33rOGZBY0=.a4acc603-0f48-4ec6-bf63-e7ad5ac8afec@github.com> Message-ID: On Wed, 8 Oct 2025 15:26:34 GMT, Francesco Andreuzzi wrote: >> The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. >> >> In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. > > test/jdk/java/net/httpclient/TimeoutBasic.java line 153: > >> 151: } >> 152: } >> 153: assert x == null; > > Is there a way to exit the loop without `x` being `null`? @fandreuz why would you want to do that? x == null means the expected cause has not been found. In which case we want to throw the AssertionError, with the root exception as the cause, possibly stripping the outer CompletionException if any as that is of little interest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27694#discussion_r2414357908 From fandreuzzi at openjdk.org Wed Oct 8 16:10:59 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Wed, 8 Oct 2025 16:10:59 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> <0jZMqGG2qzL030Gir2IMTwdLaShMvdyo0b33rOGZBY0=.a4acc603-0f48-4ec6-bf63-e7ad5ac8afec@github.com> Message-ID: On Wed, 8 Oct 2025 16:02:18 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/httpclient/TimeoutBasic.java line 153: >> >>> 151: } >>> 152: } >>> 153: assert x == null; >> >> Is there a way to exit the loop without `x` being `null`? > > @fandreuz why would you want to do that? x == null means the expected cause has not been found. In which case we want to throw the AssertionError, with the root exception as the cause, possibly stripping the outer CompletionException if any as that is of little interest. What I mean is that the assertion may not be needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27694#discussion_r2414372531 From vyazici at openjdk.org Wed Oct 8 16:17:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 8 Oct 2025 16:17:53 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v5] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 10:26:24 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's suggestion - add reachability fence Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27633#pullrequestreview-3315600726 From dfuchs at openjdk.org Wed Oct 8 16:26:12 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 16:26:12 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> <0jZMqGG2qzL030Gir2IMTwdLaShMvdyo0b33rOGZBY0=.a4acc603-0f48-4ec6-bf63-e7ad5ac8afec@github.com> Message-ID: On Wed, 8 Oct 2025 16:08:14 GMT, Francesco Andreuzzi wrote: >> @fandreuz why would you want to do that? x == null means the expected cause has not been found. In which case we want to throw the AssertionError, with the root exception as the cause, possibly stripping the outer CompletionException if any as that is of little interest. > > What I mean is that the assertion may not be needed. oh - sorry for misunderstanding. yes that's the purpose of the assertion to assert the (sometime not so) obvious. It's there for expressing intent and providing extra safety against future modifications. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27694#discussion_r2414409422 From duke at openjdk.org Wed Oct 8 16:55:31 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 16:55:31 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> Message-ID: <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> On Wed, 8 Oct 2025 15:12:45 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/module-info.java line 282: >> >>> 280: java.net.http, >>> 281: jdk.naming.dns, >>> 282: jdk.httpserver; >> >> It would be good if we could avoid giving the jdk.httpserver module access to the sun.net.* package. >> >> @dfuch @Michael-Mc-Mahon Are you sure that net.properties is the right place for this? > > @AlanBateman I hadn't realised that the HttpServer didn't already have access to `sun.net.*` - and I agree that it would be better if we did not add such an access. That said - the new property is a compatibility property - and documenting in module-info seemed a bit too much - so out of the way in `net.properties` seemed like an appealing place to add it. > > Another possibility could be to document it only in the release notes. Shall I revert the change and leave as a system property? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2414479292 From vyazici at openjdk.org Wed Oct 8 17:02:26 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 8 Oct 2025 17:02:26 GMT Subject: RFR: 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 09:30:37 GMT, Daniel Jeli?ski wrote: > Remove connectTimeout setting from all tests that set it without a good reason. It causes occasional test failures, especially on machines running tests with artificially inflated level of parallelism. > > The tests continue to pass. Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27686#pullrequestreview-3315750853 From vyazici at openjdk.org Wed Oct 8 17:23:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 8 Oct 2025 17:23:21 GMT Subject: RFR: 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 15:29:13 GMT, Daniel Fuchs wrote: > The test expects that the first request will go to the HTTP/2 server and the next will go to HTTP/3. But since the default config is to use Http3DiscoveryMode.ANY it can manage to send the first request with HTTP/3 instead. > > Requests should be explicitly configured with Http3DiscoveryMode.ALT_SVC. Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27696#pullrequestreview-3315816455 From vyazici at openjdk.org Wed Oct 8 17:31:05 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 8 Oct 2025 17:31:05 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> Message-ID: On Wed, 8 Oct 2025 15:07:17 GMT, Daniel Fuchs wrote: > The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. > > In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. Marked as reviewed by vyazici (Committer). test/jdk/java/net/httpclient/TimeoutBasic.java line 156: > 154: > 155: // print not matching exception stack trace > 156: e.printStackTrace(out); I don't know if this is intentional, but this will duplicate the stack trace in the JTreg output ? the other one will be emitted due to `throw new AssertionError` at line 165. I'm fine with keeping it, but replacing lines 155-165 with a throw new AssertionError("could not find `HttpTimeoutException` in the causal chain", x); one-liner is good enough, IMHO. ------------- PR Review: https://git.openjdk.org/jdk/pull/27694#pullrequestreview-3315840069 PR Review Comment: https://git.openjdk.org/jdk/pull/27694#discussion_r2414556970 From dfuchs at openjdk.org Wed Oct 8 17:33:57 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 8 Oct 2025 17:33:57 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> Message-ID: On Wed, 8 Oct 2025 17:28:05 GMT, Volkan Yazici wrote: >> The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. >> >> In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. > > test/jdk/java/net/httpclient/TimeoutBasic.java line 156: > >> 154: >> 155: // print not matching exception stack trace >> 156: e.printStackTrace(out); > > I don't know if this is intentional, but this will duplicate the stack trace in the JTreg output ? the other one will be emitted due to `throw new AssertionError` at line 165. I'm fine with keeping it, but replacing lines 155-165 with a > > throw new AssertionError("could not find `HttpTimeoutException` in the causal chain", x); > > one-liner is good enough, IMHO. Yes - it is intentional to have it on stdout as well as stderr. It reduces the chances of it being lost in the dreaded output overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27694#discussion_r2414563644 From duke at openjdk.org Wed Oct 8 18:31:31 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 18:31:31 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java Hello. I don't think the test provided is representative of the purpose and usage of 100 Continue. The design of this is to allow the client to avoid sending a large body if the request is going to fail. So, it sends the headers with 'Expect: 100-continue', and if the server validates and accepts them, it sends the '100 Continue' response, and then the client sends the body. Most http servers will automatically send the '100 Continue' when the 'Expect: 100-continue' is set as soon as the server handler calls getInputStream() - with the expectation that all header validation has occurred at this point. In summary, the test should send the headers, wait for the 100 Continue, then send the body, then read the response. If any of the above fails/timeouts the test should fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3382738459 From duke at openjdk.org Wed Oct 8 18:38:38 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 18:38:38 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 18:28:14 GMT, robert engels wrote: > usage of 100 Continue There are other 1xx status codes than 100 (103 for example), the point of the test isn't really as much about 100 continue as it about the ability to send a 1xx status code without closing the connection. For me this PR is just a prerequisite for a follow up PR allowing proper support for 101 switching protocols ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3382759809 From duke at openjdk.org Wed Oct 8 18:51:55 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 18:51:55 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java There is another issue with using sendResponseHeaders() for the interim responses. A filter could add response headers. when you call the sendResponseHeaders() it sends all of the headers, meaning you would send headers at this time which aren't valid. You would also send them again when you send the final response. A '103 Early Hints' does allow you to send additional headers at this time. It seems more appropriate that 100 is handled internally like Jetty does, or a new method is added sendInformationalHeaders(code,headers) that doesn't take a content length, and only sends the headers for a 103 response. 103 is really only supported (recommended) with HTTP2 so it may not matter. The server could easily be changed to never send the headers with a 1xx response. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3382793181 PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3382799175 From duke at openjdk.org Wed Oct 8 19:14:45 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 19:14:45 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 18:47:18 GMT, robert engels wrote: > There is another issue with using sendResponseHeaders() for the interim responses. A filter could add response headers. when you call the sendResponseHeaders() it sends all of the headers, meaning you would send headers at this time which aren't valid. You would also send them again when you send the final response. Is this not allowed? Don't see anywhere it says that you cannot send headers for a 1xx code. > The server could easily be changed to never send the headers with a 1xx response. See, that doesn't fly as you need to be able to send headers in cases like 101. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3382870818 From duke at openjdk.org Wed Oct 8 20:08:44 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 20:08:44 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: <5d_tHu8FaVrQ2_2Gdi6eFNrz34NzgVmyuVEfqYU78lg=.34287765-6ddb-48f1-8d9f-8e2815c4cbae@github.com> On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java I checked the rfc and it allows sending headers with 100 Continue even. Not sure why many websites (and AI) state that it cannot contain headers. RFC 9110 > A 1xx response is terminated by the end of the header section; it cannot contain content or trailers. > > A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses. Still, all of the examples I found showed no additional headers. It still seems problematic from a server api standpoint, and would seem that sendResponseHeaders() for a 1xx should send and clear, but that would certainly break everything. which is why a sendInfoResponse(code,headers) seems to make the most sense to me, and the default implementation has blank headers. but the sendInfoResponse() is probably not sufficient - as then every handler would need to handle 'Expect: 100-Continue' which doesn't seem right. Which means the server should automatically send it if needed and the handler/filter hasn't sent it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383039355 PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383045136 From duke at openjdk.org Wed Oct 8 20:38:17 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 20:38:17 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java > Not sure why many websites state that it cannot contain headers. Interesting, do you have an example? I've not seen that. > It still seems problematic from a server api standpoint How so? wouldn't only the headers of the final response matter? > every handler would need to handle 'Expect: 100-Continue' which doesn't seem right I'm afraid I fail to see the issue besides a little bit of tedium. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383138843 From duke at openjdk.org Wed Oct 8 20:41:18 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 20:41:18 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: <5d_tHu8FaVrQ2_2Gdi6eFNrz34NzgVmyuVEfqYU78lg=.34287765-6ddb-48f1-8d9f-8e2815c4cbae@github.com> References: <5d_tHu8FaVrQ2_2Gdi6eFNrz34NzgVmyuVEfqYU78lg=.34287765-6ddb-48f1-8d9f-8e2815c4cbae@github.com> Message-ID: <4hGiqddO2nnds1cue0gVbTn3DceXfcttyVaUEvNQpFI=.2b77d8d9-381d-4833-8def-83e2049d18c9@github.com> On Wed, 8 Oct 2025 20:05:52 GMT, robert engels wrote: > Which means the server should automatically send it if needed and the handler/filter hasn't sent it. I feel like that is something that can be discussed and added as a followup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383147537 From duke at openjdk.org Wed Oct 8 20:56:40 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 20:56:40 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java The RFC implies to me that the server must be the responsible for this: https://www.rfc-editor.org/rfc/rfc9110#section-10.1.1 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383204593 From duke at openjdk.org Wed Oct 8 21:03:16 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 21:03:16 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java Based on this, it seems the proper fix is for the server to detect the 'expectation' and send the 'continue' before calling the handler (after filters have had a chance to terminate, etc.), otherwise a client (or server) request could hang just calling an otherwise working handler. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383220595 From duke at openjdk.org Wed Oct 8 21:27:17 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 8 Oct 2025 21:27:17 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 20:54:00 GMT, robert engels wrote: > The RFC states the origin server must be the responsible for this: https://www.rfc-editor.org/rfc/rfc9110#section-10.1.1 We can of course make it automatic, but that's again something I think can be added later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383291289 From duke at openjdk.org Wed Oct 8 22:01:10 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 22:01:10 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java ServerImpl.java already automatically sends a 100-Continue... https://github.com/openjdk/jdk/blob/1aa62dcafd9f11ff3cb191525437e10bb789d276/src/jdk.httpserver/share/classes/sun/net/httpserver/ServerImpl.java#L865-L871 So, this is more an issue of connection upgrades. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383384284 PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383386021 From duke at openjdk.org Wed Oct 8 22:08:06 2025 From: duke at openjdk.org (robert engels) Date: Wed, 8 Oct 2025 22:08:06 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Tue, 23 Sep 2025 17:43:42 GMT, Josiah Noel 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 > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update InputRead100Test.java Btw, the sendReply for the Continue sends a Content-length header of 0 with it. I think repurposing this method for this was probably not the best idea, because all of the examples I see don't send a Content-length, because interim responses CANNOT have a body. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383399108 From duke at openjdk.org Thu Oct 9 02:09:12 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 02:09:12 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 21:58:09 GMT, robert engels wrote: > ServerImpl.java already automatically sends a 100-Continue... You truly learn something new every day. Crazy the things you miss. > So, this is more an issue of connection upgrades. For me that's pretty much the long and short of it, but I took another look at the jira issue and @Michael-Mc-Mahon did seem to mention an issue with the current implementation. > The current partial support for 100 Continue is that if an Expect: 100-Continue header was sent in the request we automatically prepend the final response with the 100 Continue. This is obviously not helpful for code that really wants to do 100 continue the way it was intended. The sequence would normally be (for example): > > Request. ----------------------------------> > Content-Length: 10000000 > Expect: 100 Continue > Interim response <---------------------- 100 Continue > Request body -----------------------------> > FInal response headers <----------------------- > Response body <--------------------------- > > So it definitely needs to be possible to send the interim response before reading the request body (as it may be delayed until receipt of the 100 response) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3383793708 From duke at openjdk.org Thu Oct 9 02:21:04 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 02:21:04 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v9] In-Reply-To: References: Message-ID: <3VHRundu6sfGeWf72G3X4dxJdFbhnmQBYuZ5jix6l40=.215fd97e-f144-45c2-8463-3231e0ef388a@github.com> > 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 Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: better test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/144110bf..ca50648e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=07-08 Stats: 55 lines in 1 file changed: 16 ins; 29 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From geliang at kernel.org Thu Oct 9 02:44:17 2025 From: geliang at kernel.org (Geliang Tang) Date: Thu, 09 Oct 2025 10:44:17 +0800 Subject: Add Extended MPTCP (Multipath TCP) Socket Option Support to OpenJDK In-Reply-To: <290d13ad-a624-44ad-8390-a73a3c3b96ec@oracle.com> References: <69f2513f5d13b65aeb3fd23c9fcc6dc410968466.camel@kernel.org> <290d13ad-a624-44ad-8390-a73a3c3b96ec@oracle.com> Message-ID: <9dcbf6216f8e603cd7b31c84f94772db797694b3.camel@kernel.org> Hi Jaikiran, Alan, Thank you for your reply, and I'm sorry for my delayed response. On Tue, 2025-09-23 at 21:33 +0530, Jaikiran Pai wrote: > Hello Geliang, > > Just a few initial observations: > > On 23/09/25 3:04 pm, Geliang Tang wrote: > > Dear OpenJDK Maintainers, > > > > We are writing to propose the integration of Multipath TCP (MPTCP) > > support into OpenJDK. In response to Alan's feedback in earlier > > discussions [1], we have developed a Java-based implementation that > > utilizes the setOption method to enable MPTCP before binding or > > connecting a socket, as illustrated below: > > > > ?? Socket c = new Socket(); > > ?? c.setOption(ExtendedSocketOptions.TCP_MPTCPIFY, true); > > ?? c.connect(new InetSocketAddress(loop.getHostAddress(), port)); > > > > The name 'TCP_MPTCPIFY' was chosen to align with 'mptcpize' tool in > > mptcpd and 'mptcpify' in BCC. The complete implementation can be > > found > > in [2]. > I realize it's still a bit early to discuss naming of this option, > but > if we do go ahead with this approach of introducing an > ExtendedSocketOption, then maybe calling it TCP_MULTIPATH might be > more > suitable. Thank you for your suggestion. I agree that TCP_MULTIPATH is a better name, and I will adopt it in future versions. > > This email outlines the technical background and aims to facilitate > > further discussion on the proposed approach. > > Looking at the linked github diff in your mail, the biggest > difference > between existing (Extended)SocketOptions and this new proposed one is > that, as far as I can tell, this new one isn't a socket option and > instead is a protocol value that is used when constructing the > socket(): > > ?> fdm = socket(domain, type, IPPROTO_MPTCP); > > I don't yet know if fitting this into the existing > ExtendedSocketOptions > may end up being tricky for long term maintenance of this (internal) I apologize for forgetting to provide some historical version information here. The initial version of OpenJDK MPTCP was indeed implemented by extending Java_sun_nio_ch_Net_socket0. The complete modifications can be viewed here: https://patchwork.kernel.org/project/mptcp/cover/cover.1756369940.git.tanggeliang at kylinos.cn The drawback is that it modified the standard API of Socket/ServerSocket. Therefore, following Alan's suggestion, we referenced Java_sun_net_sdp_SdpSupport_convert0 and implemented this version that supports MPTCP through Socket Options. > API. The other question this raises is, are applications allowed to > call > Socket.getOption(...) for this option and then expect it to return > true/false depending on whether multicast TCP was set for that > socket? I > briefly glanced at the proposed diff and I couldn't spot any changes > in > the ExtendedSocketOptions.getOption(...) code to deal with this > option. > But that too I think is a trivial thing for later. Thank you for the reminder. I will consider implementing getOption in future versions. > > The bigger question, I think, is whether constructing a "socket()" > with > a specific "protocol" value in this manner by trying to adjust the > implementation in the code which deals with socket options is the > right > thing to do. I realize that this proposal of prototyping it as a > socket > option was suggested in response to your first email, so I am not > saying > this direction should be abandoned, I just haven't fully grasped if > this > can cause us problems with this approach. By comparing the previous version that extended socket() with this Socket Option-based version, we believe the latter is superior as it involves minimal changes to the API and is easier to maintain. > > I have several other questions, both implementation details as well > as > the basics of multipath TCP, but I haven't yet read up on all the > material that's been linked in your email. So I'll catch up on that > first. Looking forward to more of your suggestions. Thank you very much. -Geliang > > -Jaikiran > From duke at openjdk.org Thu Oct 9 04:02:41 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 04:02:41 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v10] In-Reply-To: References: Message-ID: > 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 Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: allow manual 100-Continue processing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/ca50648e..4b005888 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=08-09 Stats: 63 lines in 6 files changed: 47 ins; 14 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 04:37:04 2025 From: duke at openjdk.org (robert engels) Date: Thu, 9 Oct 2025 04:37:04 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: References: Message-ID: <7e72OwDzLnPv_6k8ZZoNvUad3uyOkJ3kFo_6UfzUlBM=.7ea24a2b-343f-4c33-b01e-8a5ba868621e@github.com> On Fri, 3 Oct 2025 10:23:55 GMT, Michael McMahon wrote: >>> I intend to do a more thorough review in the coming days. >> >> I'm sure that when you get time to review in earnest, you'll find it quite hard to believe that these changes have any relation. > > I'm okay with @SentryMan fixing this. I filed another issue for the API change that I suggested (https://bugs.openjdk.org/browse/JDK-8368955) and I will open a PR for that after this issue is fixed. > For me that's pretty much the long and short of it, but I took another look at the jira issue and @Michael-Mc-Mahon did seem to mention an issue with the current implementation. > > > I don't think this is an issue. The continue is sent before the request body is read. What you can't do is other inspection of the headers to maybe error the request instead of sending the continue. The recent PR to only send the continue when the input stream is read fixes that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3384085154 From duke at openjdk.org Thu Oct 9 04:45:07 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 04:45:07 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v8] In-Reply-To: <7e72OwDzLnPv_6k8ZZoNvUad3uyOkJ3kFo_6UfzUlBM=.7ea24a2b-343f-4c33-b01e-8a5ba868621e@github.com> References: <7e72OwDzLnPv_6k8ZZoNvUad3uyOkJ3kFo_6UfzUlBM=.7ea24a2b-343f-4c33-b01e-8a5ba868621e@github.com> Message-ID: <1wjIMVlL3giRHCgMPlh1xxIe8tiuRaaarkdyKfelmsg=.820bd039-b008-4054-b061-7cc9023a5d0e@github.com> On Thu, 9 Oct 2025 04:33:54 GMT, robert engels wrote: > The recent PR to only send the continue when the input stream is read fixes that. I assume you mean the recent commit. Anyways, perchance @robaho could I have your review on these new changes? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3384097246 From djelinski at openjdk.org Thu Oct 9 09:23:26 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 9 Oct 2025 09:23:26 GMT Subject: RFR: 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds In-Reply-To: <9qgyWvoEZIGylB3uglmUX0IdbVqoKTRr40T_S7GU4Yw=.9b1fd694-1941-4368-9900-2687acbed08c@github.com> References: <9qgyWvoEZIGylB3uglmUX0IdbVqoKTRr40T_S7GU4Yw=.9b1fd694-1941-4368-9900-2687acbed08c@github.com> Message-ID: On Wed, 8 Oct 2025 10:22:06 GMT, Jaikiran Pai wrote: >> Remove connectTimeout setting from all tests that set it without a good reason. It causes occasional test failures, especially on machines running tests with artificially inflated level of parallelism. >> >> The tests continue to pass. > > This looks reasonable to me. Thanks @jaikiran @dfuch @vy for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27686#issuecomment-3384940858 From djelinski at openjdk.org Thu Oct 9 09:23:27 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 9 Oct 2025 09:23:27 GMT Subject: Integrated: 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 09:30:37 GMT, Daniel Jeli?ski wrote: > Remove connectTimeout setting from all tests that set it without a good reason. It causes occasional test failures, especially on machines running tests with artificially inflated level of parallelism. > > The tests continue to pass. This pull request has now been integrated. Changeset: b37a1a33 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/b37a1a33aebaf86223eb94b3d641a5bed66f9e20 Stats: 7 lines in 5 files changed: 0 ins; 7 del; 0 mod 8369291: Test java/net/httpclient/http3/H3DataLimitsTest.java fails in quic connection timeout with linux fastdebug builds Reviewed-by: jpai, dfuchs, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/27686 From dfuchs at openjdk.org Thu Oct 9 09:26:19 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 09:26:19 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v10] In-Reply-To: References: Message-ID: <9uodc9dMkf9ZoNFFJHoLvLLzuFLOI-Kog6SHQvt6AMo=.01738c5b-f40e-4721-98e4-8b82d6f24fb6@github.com> On Thu, 9 Oct 2025 04:02:41 GMT, Josiah Noel 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: > > allow manual 100-Continue processing Hi guys, I would prefer if we handled any changes to the 100 - continue behaviour in a separate fix. That would be easier to review and to discuss options. So I'd suggest to revert [4b00588](https://github.com/openjdk/jdk/pull/27069/commits/4b0058886cf10b1703426acc4131453c46636645) in this PR and possibly discuss that in a followup. Lets keep separate issues separate. The code that handles 100 in ServerImpl is attributed to `duke` which tells me it's been there for a long time :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3384961130 From jpai at openjdk.org Thu Oct 9 12:00:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 9 Oct 2025 12:00:05 GMT Subject: RFR: 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 15:29:13 GMT, Daniel Fuchs wrote: > The test expects that the first request will go to the HTTP/2 server and the next will go to HTTP/3. But since the default config is to use Http3DiscoveryMode.ANY it can manage to send the first request with HTTP/3 instead. > > Requests should be explicitly configured with Http3DiscoveryMode.ALT_SVC. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27696#pullrequestreview-3318611269 From duke at openjdk.org Thu Oct 9 13:08:31 2025 From: duke at openjdk.org (robert engels) Date: Thu, 9 Oct 2025 13:08:31 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v10] In-Reply-To: <9uodc9dMkf9ZoNFFJHoLvLLzuFLOI-Kog6SHQvt6AMo=.01738c5b-f40e-4721-98e4-8b82d6f24fb6@github.com> References: <9uodc9dMkf9ZoNFFJHoLvLLzuFLOI-Kog6SHQvt6AMo=.01738c5b-f40e-4721-98e4-8b82d6f24fb6@github.com> Message-ID: On Thu, 9 Oct 2025 09:23:59 GMT, Daniel Fuchs wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> allow manual 100-Continue processing > > Hi guys, I would prefer if we handled any changes to the 100 - continue behaviour in a separate fix. That would be easier to review and to discuss options. So I'd suggest to revert [4b00588](https://github.com/openjdk/jdk/pull/27069/commits/4b0058886cf10b1703426acc4131453c46636645) in this PR and possibly discuss that in a followup. Lets keep separate issues separate. The code that handles 100 in ServerImpl is attributed to `duke` which tells me it's been there for a long time :-) @dfuch i agree. I don?t think there is anything to do here. The 100-Continue is already properly sent - if a bit limited. I think the ability to ?switch protocols? is a different bug. So what exactly needs to be fixed here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3385782389 From duke at openjdk.org Thu Oct 9 13:32:47 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 13:32:47 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v10] In-Reply-To: <9uodc9dMkf9ZoNFFJHoLvLLzuFLOI-Kog6SHQvt6AMo=.01738c5b-f40e-4721-98e4-8b82d6f24fb6@github.com> References: <9uodc9dMkf9ZoNFFJHoLvLLzuFLOI-Kog6SHQvt6AMo=.01738c5b-f40e-4721-98e4-8b82d6f24fb6@github.com> Message-ID: On Thu, 9 Oct 2025 09:23:59 GMT, Daniel Fuchs wrote: > Hi guys, I would prefer if we handled any changes to the 100 - continue behaviour in a separate fix. That would be easier to review and to discuss options. So I'd suggest to revert [4b00588](https://github.com/openjdk/jdk/pull/27069/commits/4b0058886cf10b1703426acc4131453c46636645) in this PR and possibly discuss that in a followup. I can remove, but if we can neither manually send 100-continue to resolve the issue described by @Michael-Mc-Mahon, or 101-switching protocols as I originally wanted, what exactly does this PR accomplish? The only other 1xx http code is 103, which as we know is recommended for use only with http2 (that I can't use because I can't send 101 properly to upgrade the connection) So effectively there are no interim responses to send with this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3385903211 From duke at openjdk.org Thu Oct 9 13:46:45 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 13:46:45 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v11] In-Reply-To: References: Message-ID: > 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 two additional commits since the last revision: - Fail test if continue sent twice - Revert "allow manual 100-Continue processing" This reverts commit 4b0058886cf10b1703426acc4131453c46636645. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/4b005888..8abfba3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=09-10 Stats: 30 lines in 6 files changed: 14 ins; 15 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 14:04:58 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 14:04:58 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: > 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 two additional commits since the last revision: - Update InputRead100Test.java - actually fail if sent twice ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/8abfba3a..8cc60c69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=10-11 Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 14:04:59 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 14:04:59 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v10] In-Reply-To: References: <9uodc9dMkf9ZoNFFJHoLvLLzuFLOI-Kog6SHQvt6AMo=.01738c5b-f40e-4721-98e4-8b82d6f24fb6@github.com> Message-ID: On Thu, 9 Oct 2025 13:29:28 GMT, Josiah Noel wrote: > So I'd suggest to revert [4b00588](https://github.com/openjdk/jdk/pull/27069/commits/4b0058886cf10b1703426acc4131453c46636645) in this PR and possibly discuss that in a followup. The current implementation auto sends 100-continue before even reaching the handler. So with `4b00588` reverted if we try to send a 100 code with sendResponseHeaders, we are violating the expectation because we are again sending 100-continue instead of the final response. I have updated the test to show this problem and naturally they fail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3385986059 From dfuchs at openjdk.org Thu Oct 9 14:29:23 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 14:29:23 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:04:58 GMT, Josiah Noel 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 two additional commits since the last revision: > > - Update InputRead100Test.java > - actually fail if sent twice > [actually fail if sent twice](https://github.com/openjdk/jdk/pull/27069/commits/b022de38565f92783b52631298f441faee5806be) I am not sure I understand that. The client should expect to receive 100 twice in that case, since we haven't changed the server auto-handling of 100 continue behavior in this PR. It would also be good to test that a made up `123` informational code can be sent (and received) several times before the final response. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386141148 From duke at openjdk.org Thu Oct 9 14:33:53 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 14:33:53 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:26:27 GMT, Daniel Fuchs wrote: > The client should expect to receive 100 twice in that case, It's a bit strange though, If I'm a client calling an API expecting a 100 code, I'm not expecting to receive two 100 codes, I'm expecting the 100 code, then the final response code after I send the body. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386161724 From dfuchs at openjdk.org Thu Oct 9 14:40:50 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 14:40:50 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:04:58 GMT, Josiah Noel 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 two additional commits since the last revision: > > - Update InputRead100Test.java > - actually fail if sent twice Noted. But https://www.rfc-editor.org/rfc/rfc7231.html#section-6.2 > A client MUST be able to parse one or more 1xx responses received > prior to a final response, even if the client does not expect one. A > user agent MAY ignore unexpected 1xx responses. I don't see anything hinting that 100 should be special in this respect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386179239 From duke at openjdk.org Thu Oct 9 14:40:50 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 14:40:50 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:35:59 GMT, Daniel Fuchs wrote: > Noted. alright then ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386182151 From duke at openjdk.org Thu Oct 9 14:40:51 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 14:40:51 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:04:58 GMT, Josiah Noel 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 two additional commits since the last revision: > > - Update InputRead100Test.java > - actually fail if sent twice I'll file a separate bug for fixing 100-continue then ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386183993 From duke at openjdk.org Thu Oct 9 14:44:31 2025 From: duke at openjdk.org (eolcoderllc) Date: Thu, 9 Oct 2025 14:44:31 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: <8JmDlMYOxBZlBxEhNJqgTrWs6d8aCkPpKOjB6CWUTRA=.31b63041-b79e-45a9-973b-9632b28cfbed@github.com> On Thu, 9 Oct 2025 14:04:58 GMT, Josiah Noel 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 two additional commits since the last revision: > > - Update InputRead100Test.java > - actually fail if sent twice The rfc implies that the can send multiple 100 Continue interim responses. A client is supposed to ignore unexpected 1xx codes. A second 190 Continue would be unexpected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386192800 From duke at openjdk.org Thu Oct 9 14:53:22 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 14:53:22 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v13] In-Reply-To: References: Message-ID: > 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: Revert "Update InputRead100Test.java" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/8cc60c69..2afaeb89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From dfuchs at openjdk.org Thu Oct 9 15:11:43 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 15:11:43 GMT Subject: Integrated: 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 15:29:13 GMT, Daniel Fuchs wrote: > The test expects that the first request will go to the HTTP/2 server and the next will go to HTTP/3. But since the default config is to use Http3DiscoveryMode.ANY it can manage to send the first request with HTTP/3 instead. > > Requests should be explicitly configured with Http3DiscoveryMode.ALT_SVC. This pull request has now been integrated. Changeset: 48d21b50 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/48d21b50faed61eaa4f1d115531a21d0c29a5dff Stats: 21 lines in 1 file changed: 12 ins; 4 del; 5 mod 8369434: java/net/httpclient/AltServiceUsageTest.java fails intermittently Reviewed-by: vyazici, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27696 From dfuchs at openjdk.org Thu Oct 9 15:26:42 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 15:26:42 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v12] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:35:59 GMT, Daniel Fuchs wrote: >> Josiah Noel has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update InputRead100Test.java >> - actually fail if sent twice > > Noted. But https://www.rfc-editor.org/rfc/rfc7231.html#section-6.2 >> A client MUST be able to parse one or more 1xx responses received >> prior to a final response, even if the client does not expect one. A >> user agent MAY ignore unexpected 1xx responses. > > I don't see anything hinting that 100 should be special in this respect. > @dfuch i agree. I don?t think there is anything to do here. The 100-Continue is already properly sent - if a bit limited. I think the ability to ?switch protocols? is a different bug. So what exactly needs to be fixed here? We want to be able to send N 1xx response codes before sending the final response, without `sendResponseHeaders` considering that the final response has been sent, or that the output stream needs to be closed. At this point we are not interested in the semantics of the 1xx codes. They will either be recognized and handled by the client, or not recognized and discarded. Adhering to the semantics of the code should be the business of the application that sends them. For 100 we could envisage a followup to provide some means for the application to control whether it wants to send 100 or 417. For 101 I am still not convinced we should support it - but that can be discussed - though not in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386241887 From jpai at openjdk.org Thu Oct 9 15:45:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 9 Oct 2025 15:45:39 GMT Subject: RFR: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> Message-ID: On Wed, 8 Oct 2025 15:07:17 GMT, Daniel Fuchs wrote: > The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. > > In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. This looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27694#pullrequestreview-3319561810 From duke at openjdk.org Thu Oct 9 15:50:30 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 15:50:30 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v14] In-Reply-To: References: Message-ID: > 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: test multiple 100 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/2afaeb89..84aebe9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=12-13 Stats: 12 lines in 1 file changed: 6 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From dfuchs at openjdk.org Thu Oct 9 15:50:32 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 15:50:32 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v13] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 14:53:22 GMT, Josiah Noel 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: > > Revert "Update InputRead100Test.java" I'd suggesst to rename `InputRead100Test` to something like `Send1xxResponsesTest` and add more methods to it. Rename the current methods in that test to include 100 in their name, since they are testing the special case of 100. Add an additional test method where the server sends code `123` 3 times before sending the final response and check that the client receives all three. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386404094 From duke at openjdk.org Thu Oct 9 15:54:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 15:54:02 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v15] In-Reply-To: References: Message-ID: > 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: pr comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/84aebe9b..c8fbcba2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=13-14 Stats: 14 lines in 1 file changed: 7 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From dfuchs at openjdk.org Thu Oct 9 15:55:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 15:55:52 GMT Subject: Integrated: 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain In-Reply-To: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> References: <3Go5wOMpTnRkJCHieZJ-_CYLTaWmGwZsIhtELBwNgSI=.a4541589-fed5-476f-822e-44e72a1b98cc@github.com> Message-ID: <6t5qiIw0xdZE871qB45vgovJixyOm8UB3ThrnkZsOG4=.8b493906-0a63-4e68-9313-d3ae7a5a6f0e@github.com> On Wed, 8 Oct 2025 15:07:17 GMT, Daniel Fuchs wrote: > The TimeoutBasic.java test expects that HttpTimeoutException will be either the root cause, or the cause of the root cause of a CompletionException, while in fact it could be further down the cause chain. The test logic should be relaxed to allow that. > > In addition I have logged a followup RFE ([JDK-8369315](https://bugs.openjdk.org/browse/JDK-8369315)) to possibly revisit the wrapping of HttpTimeoutExceptions. This pull request has now been integrated. Changeset: 9891cd69 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/9891cd69e442cdfa6fb76ecbd20391291f4bf6ad Stats: 40 lines in 1 file changed: 26 ins; 11 del; 3 mod 8369313: java/net/httpclient/TimeoutBasic.java should accept that HttpTimeoutException should be somewhere down the cause chain Reviewed-by: vyazici, jpai ------------- PR: https://git.openjdk.org/jdk/pull/27694 From duke at openjdk.org Thu Oct 9 15:59:33 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 15:59:33 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v16] In-Reply-To: References: Message-ID: > 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: fix message ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/c8fbcba2..9d3f0943 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 16:02:22 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 16:02:22 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v15] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 15:54:02 GMT, Josiah Noel 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: > > pr comment I still kept the 100 but I'm testing whether three 100 responses are sent, is that fine? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386458714 From dfuchs at openjdk.org Thu Oct 9 16:25:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 16:25:52 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v15] In-Reply-To: References: Message-ID: <2RASqmvw1M6rj9RPJ1COO7WV3-iTAKJGkZkj5M4ls8k=.1df15a8c-38cb-4b7c-99c1-482ea55909e5@github.com> On Thu, 9 Oct 2025 15:54:02 GMT, Josiah Noel 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: > > pr comment test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 62: > 60: @Test > 61: public void testAutoContinue() throws Exception { > 62: System.out.println("testContinue()"); Suggestion: System.out.println("testAutoContinue()"); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 63: > 61: public void testAutoContinue() throws Exception { > 62: System.out.println("testContinue()"); > 63: InetAddress loopback = InetAddress.getLoopbackAddress(); Suggestion: InetAddress loopback = InetAddress.getLoopbackAddress(); String replyMsg = "Here is my reply!"; test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 70: > 68: msg -> { > 69: System.err.println("Handling request: " + msg.getRequestURI()); > 70: byte[] reply = "Here is my reply!".getBytes(UTF_8); Suggestion: byte[] reply = replyMsg.getBytes(UTF_8); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 74: > 72: msg.getRequestBody().readAllBytes(); > 73: msg.sendResponseHeaders(100, -1); > 74: msg.sendResponseHeaders(100, -1); Manually sending 100 is tested by the other test method. Suggestion: test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 85: > 83: System.out.println("Server started at port " + server.getAddress().getPort()); > 84: > 85: runRawSocketHttpClient(loopback, server.getAddress().getPort(), 0); Suggestion: runRawSocketHttpClient(loopback, server.getAddress().getPort(), true, replyMsg, 100, 200); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 95: > 93: @Test > 94: public void testManualContinue() throws Exception { > 95: System.out.println("testAutoContinue()"); Suggestion: System.out.println("testManualContinue()"); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 96: > 94: public void testManualContinue() throws Exception { > 95: System.out.println("testAutoContinue()"); > 96: InetAddress loopback = InetAddress.getLoopbackAddress(); Suggestion: InetAddress loopback = InetAddress.getLoopbackAddress(); String replyMsg = "Here is my other reply!"; test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 103: > 101: msg -> { > 102: System.err.println("Handling request: " + msg.getRequestURI()); > 103: byte[] reply = "Here is my reply!".getBytes(UTF_8); Suggestion: byte[] reply = replyMsg.getBytes(UTF_8); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 119: > 117: System.out.println("Server started at port " + server.getAddress().getPort()); > 118: > 119: runRawSocketHttpClient(loopback, server.getAddress().getPort(), 0); Suggestion: runRawSocketHttpClient(loopback, server.getAddress().getPort(), true, replyMsg, 100, 100, 100, 100, 200); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 127: > 125: } > 126: > 127: static void runRawSocketHttpClient(InetAddress address, int port, int contentLength) Suggestion: static void runRawSocketHttpClient(InetAddress address, int port, boolean exoectContinue, String expectedReply, int... epectedStatusCodes) test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 150: > 148: writer.print("Content-Length: " + contentLength + CRLF); > 149: writer.print("Connection: keep-alive" + CRLF); > 150: writer.print("Expect: 100-continue" + CRLF); Suggestion: if (expectContinue) { writer.print("Expect: 100-continue" + CRLF); } test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 171: > 169: else if (line.startsWith("HTTP/1.1 100")) { > 170: foundContinue = true; > 171: } Change that to build a list of received status codes test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 175: > 173: if (!foundThirdContinue) { > 174: throw new IOException("Did not receive two 100 continue from server"); > 175: } Move that to after having received the final staus code, verifying that the received codes correspond to what was passed in parameter. test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 186: > 184: break; > 185: } > 186: System.out.println("final response \"" + line + "\""); add the final code to the list and verify the list matches. Read the body and verify it matches too. test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 191: > 189: } finally { > 190: // give time to the server to try & drain its input stream > 191: Thread.sleep(500); Not sure why we need that sleep? test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 199: > 197: // give time to the server to trigger its assertion > 198: // error before closing the connection > 199: Thread.sleep(500); Which assertion error is that? test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 216: > 214: System.out.println("Client finished."); > 215: } > 216: } Please add new line at the end. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417230889 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417248852 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417249814 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417234936 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417251104 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417253981 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417256808 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417257669 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417265085 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417270204 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417274147 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417282180 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417289995 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417301310 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417302346 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417304703 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417305611 From dfuchs at openjdk.org Thu Oct 9 16:28:39 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 16:28:39 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v17] In-Reply-To: <34dJDkuupDFcjWoGWLe7GgoeAtE3YnCau7tguI0nKdo=.bf4c68fe-4ad6-4d2e-8d0c-8c75ef3328bf@github.com> References: <34dJDkuupDFcjWoGWLe7GgoeAtE3YnCau7tguI0nKdo=.bf4c68fe-4ad6-4d2e-8d0c-8c75ef3328bf@github.com> Message-ID: On Thu, 9 Oct 2025 16:10:16 GMT, Josiah Noel 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 FYI - [JDK-8369513](https://bugs.openjdk.org/browse/JDK-8369513) - let's finish this PR first... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386599174 From dfuchs at openjdk.org Thu Oct 9 16:25:53 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 16:25:53 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v15] In-Reply-To: <2RASqmvw1M6rj9RPJ1COO7WV3-iTAKJGkZkj5M4ls8k=.1df15a8c-38cb-4b7c-99c1-482ea55909e5@github.com> References: <2RASqmvw1M6rj9RPJ1COO7WV3-iTAKJGkZkj5M4ls8k=.1df15a8c-38cb-4b7c-99c1-482ea55909e5@github.com> Message-ID: On Thu, 9 Oct 2025 16:20:29 GMT, Daniel Fuchs wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> pr comment > > test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 216: > >> 214: System.out.println("Client finished."); >> 215: } >> 216: } > > Please add new line at the end. Also please add a method named - e.g - testSending123() that should be very similar to `testManualContinue()` but sends 123 instead of 100. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417310534 From duke at openjdk.org Thu Oct 9 16:10:16 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 16:10:16 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v17] In-Reply-To: References: Message-ID: <34dJDkuupDFcjWoGWLe7GgoeAtE3YnCau7tguI0nKdo=.bf4c68fe-4ad6-4d2e-8d0c-8c75ef3328bf@github.com> > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/9d3f0943..e1ce09d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=15-16 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 17:25:55 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 17:25:55 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v18] In-Reply-To: References: Message-ID: > 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 two additional commits since the last revision: - Update Send1xxResponsesTest.java - pr comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/e1ce09d9..f9dc2650 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=16-17 Stats: 91 lines in 1 file changed: 56 ins; 18 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 17:25:56 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 17:25:56 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v17] In-Reply-To: References: <34dJDkuupDFcjWoGWLe7GgoeAtE3YnCau7tguI0nKdo=.bf4c68fe-4ad6-4d2e-8d0c-8c75ef3328bf@github.com> Message-ID: On Thu, 9 Oct 2025 16:26:13 GMT, Daniel Fuchs wrote: > FYI - [JDK-8369513](https://bugs.openjdk.org/browse/JDK-8369513) - let's finish this PR first... naturally, though I'll probably get to that after [JDK-8368695](https://bugs.openjdk.org/browse/JDK-8368695). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386830701 From duke at openjdk.org Thu Oct 9 17:42:04 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 17:42:04 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v18] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 17:26:31 GMT, Daniel Fuchs wrote: > the spec allows for the client to send the body before receiving 100 because servers might ignore the Expect header precisely ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417468238 From dfuchs at openjdk.org Thu Oct 9 17:42:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 17:42:03 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v18] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 17:25:55 GMT, Josiah Noel 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 two additional commits since the last revision: > > - Update Send1xxResponsesTest.java > - pr comments test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 98: > 96: @Test > 97: public void testManualContinue() throws Exception { > 98: System.out.println("testAutoContinue()"); Suggestion: System.out.println("testManualContinue()"); test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 192: > 190: // there's more into the request. > 191: writer.print(body); > 192: System.out.println("Client wrote body to socket: " + socket); if expectContinue == true shouldn't we wait to get the first 100 before sending the body? or maybe not - the spec allows for the client to send the body before receiving 100 because servers might ignore the Expect header... Since we're testing the server side here - maybe it's fine to send the body immediately as you suggest. test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 221: > 219: // Assert that the received status codes match the expected ones > 220: if (statusCodes.size() != expectedStatusCodes.length) { > 221: throw new IOException("Expected " + expectedStatusCodes.length + " status codes, but got " + statusCodes.size()); it would be more informative to print the two lists here - rather than the lengths. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417469431 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417460219 PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417465319 From dfuchs at openjdk.org Thu Oct 9 17:42:05 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 9 Oct 2025 17:42:05 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v19] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 17:38:57 GMT, Josiah Noel 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 two additional commits since the last revision: > > - Update Send1xxResponsesTest.java > - Update Send1xxResponsesTest.java test/jdk/com/sun/net/httpserver/Send1xxResponsesTest.java line 223: > 221: if (statusCodes.size() != expectedStatusCodes.length) { > 222: System.out.println("Expected status codes: " + Arrays.toString(expectedStatusCodes)); > 223: System.out.println("Received status codes: " + statusCodes); Sorry, I was not clear. I meant include the lists in the exception message - not print them in stdout ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27069#discussion_r2417483737 From duke at openjdk.org Thu Oct 9 17:42:00 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 17:42:00 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v19] In-Reply-To: References: Message-ID: > 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 two additional commits since the last revision: - Update Send1xxResponsesTest.java - Update Send1xxResponsesTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/f9dc2650..52fc572c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=17-18 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 17:57:57 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 17:57:57 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v20] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/52fc572c..071a7668 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=18-19 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From duke at openjdk.org Thu Oct 9 18:12:52 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 9 Oct 2025 18:12:52 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27069/files - new: https://git.openjdk.org/jdk/pull/27069/files/071a7668..b56541c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27069&range=19-20 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27069/head:pull/27069 PR: https://git.openjdk.org/jdk/pull/27069 From michaelm at openjdk.org Fri Oct 10 10:18:54 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 10 Oct 2025 10:18:54 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel 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 I have to say I'm a bit uncomfortable trying to shoe-horn all this functionality into the existing method `sendResponseHeaders`. There are significant behavioral implications for the server with each of the `1XX` intermediate response codes. Take `103 early Hints` for example. That is usually sent with a `Link` header in the intermediate response. Where would the header come from? If it's the response headers returned from `getResponseHeaders` then is this map cleared after the intermediate response or is the user supposed to clear it? Does this work? If we are supporting `100 Continue` now (under user control) does the expected behavior work? If a client sends a request with an `Expect: 100-Continue` header and waits for the intermediate response before sending the request body, does this actually work? I know we have partial support for it already. But, I'd like to see tests and apidoc documenting all of this before we consider adding it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3389207562 From djelinski at openjdk.org Fri Oct 10 10:22:00 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 10 Oct 2025 10:22:00 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() Message-ID: Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. The existing ContentLengthHeaderTest was extended to cover the modified scenarios. Tier1-3 tests continue to pass. ------------- Commit messages: - Do not send content-length if body is empty and the method doesn't expect any Changes: https://git.openjdk.org/jdk/pull/27727/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358942 Stats: 112 lines in 2 files changed: 108 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27727/head:pull/27727 PR: https://git.openjdk.org/jdk/pull/27727 From dfuchs at openjdk.org Fri Oct 10 11:04:18 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 11:04:18 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 13:27:42 GMT, Daniel Jeli?ski wrote: > Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. > > This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. > > The existing ContentLengthHeaderTest was extended to cover the modified scenarios. > > Tier1-3 tests continue to pass. test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 202: > 200: assertEquals(resp.version(), version); > 201: } > 202: Maybe you should add a test that verifies that Content-Length: 0 is still sent if you do: HttpRequest req = HttpRequest.newBuilder() .version(version) .method("GET", HttpRequest.BodyPublishers.noBody()) .header("Content-Length", "0") .uri(uri) .build(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2419447591 From dfuchs at openjdk.org Fri Oct 10 11:15:29 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 11:15:29 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 10:14:03 GMT, Michael McMahon wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Send1xxResponsesTest.java > > I have to say I'm a bit uncomfortable trying to shoe-horn all this functionality into the existing method `sendResponseHeaders`. There are significant behavioral implications for the server with each of the `1XX` intermediate response codes. Take `103 early Hints` for example. That is usually sent with a `Link` header in the intermediate response. Where would the header come from? If it's the response headers returned from `getResponseHeaders` then is this map cleared after the intermediate response or is the user supposed to clear it? Does this work? > > If we are supporting `100 Continue` now (under user control) does the expected behavior work? If a client sends a request with an `Expect: 100-Continue` header and waits for the intermediate response before sending the request body, does this actually work? I know we have partial support for it already. But, I'd like to see tests and apidoc documenting all of this before we consider adding it. @Michael-Mc-Mahon are you suggesting we should add a new API to send informational codes instead, and throw in `sendResponseHeaders()` if the status is >= 100 and < 200? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3389433714 From michaelm at openjdk.org Fri Oct 10 12:00:12 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 10 Oct 2025 12:00:12 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 10:14:03 GMT, Michael McMahon wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Send1xxResponsesTest.java > > I have to say I'm a bit uncomfortable trying to shoe-horn all this functionality into the existing method `sendResponseHeaders`. There are significant behavioral implications for the server with each of the `1XX` intermediate response codes. Take `103 early Hints` for example. That is usually sent with a `Link` header in the intermediate response. Where would the header come from? If it's the response headers returned from `getResponseHeaders` then is this map cleared after the intermediate response or is the user supposed to clear it? Does this work? > > If we are supporting `100 Continue` now (under user control) does the expected behavior work? If a client sends a request with an `Expect: 100-Continue` header and waits for the intermediate response before sending the request body, does this actually work? I know we have partial support for it already. But, I'd like to see tests and apidoc documenting all of this before we consider adding it. > @Michael-Mc-Mahon are you suggesting we should add a new API to send informational codes instead, and throw in `sendResponseHeaders()` if the status is >= 100 and < 200? That was my initial expectation. I was expecting a new method like `sendIntermediateResponse(int code, Headers headers)` If we're not adding a new API, then I think all the above questions need answers and the spec for sendResponseHeaders updated to spell out how all this functionality would work, with tests showing it. Either way, I think this change needs a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3389698975 From djelinski at openjdk.org Fri Oct 10 12:04:28 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 10 Oct 2025 12:04:28 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: > Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. > > This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. > > The existing ContentLengthHeaderTest was extended to cover the modified scenarios. > > Tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Add test explicitly setting content length to zero ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27727/files - new: https://git.openjdk.org/jdk/pull/27727/files/11892a75..fc6a7edb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=00-01 Stats: 17 lines in 1 file changed: 17 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27727/head:pull/27727 PR: https://git.openjdk.org/jdk/pull/27727 From djelinski at openjdk.org Fri Oct 10 12:04:31 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 10 Oct 2025 12:04:31 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 11:01:23 GMT, Daniel Fuchs wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test explicitly setting content length to zero > > test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 202: > >> 200: assertEquals(resp.version(), version); >> 201: } >> 202: > > Maybe you should add a test that verifies that Content-Length: 0 is still sent if you do: > > > HttpRequest req = HttpRequest.newBuilder() > .version(version) > .method("GET", HttpRequest.BodyPublishers.noBody()) > .header("Content-Length", "0") > .uri(uri) > .build(); Thanks for the suggestion. I added the test. Note that the `content-length` header is restricted by default, and had to be explicitly allowed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2419735215 From myankelevich at openjdk.org Fri Oct 10 12:50:42 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 10 Oct 2025 12:50:42 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: References: Message-ID: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> > 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). Mikhail Yankelevich 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 four additional commits since the last revision: - race condition fix - Merge branch 'master' into JDK-8368625 - race condition fix - JDK-8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27670/files - new: https://git.openjdk.org/jdk/pull/27670/files/7ace98c1..d272f961 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=00-01 Stats: 8884 lines in 224 files changed: 6433 ins; 1570 del; 881 mod Patch: https://git.openjdk.org/jdk/pull/27670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27670/head:pull/27670 PR: https://git.openjdk.org/jdk/pull/27670 From myankelevich at openjdk.org Fri Oct 10 12:50:43 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 10 Oct 2025 12:50:43 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 In-Reply-To: References: Message-ID: On Tue, 7 Oct 2025 15:50:30 GMT, Mark Sheppard 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). > > The extending of the stop duration may not have the desired effect of eliminating what appears to be a race condition in the test > > One of the recorded failures is for the temporal condition > > // The shutdown should take at least as long as the exchange duration > if (elapsed < exchangeDuration.toNanos()) { > fail("HttpServer.stop terminated before exchange completed"); > } > > This is a somewhat dubious constraint and can?t always be met > > The test assumes that the participating threads are all actively executing simultaneously, which may not be true > They may be scheduled to run rather than actually running. > > Restating the objective of the test > Objective: to ensure that the stop request is not processed while there are extant exchanges > > Potential race scenario: > > Server started creates exchange which waits for a signal to complete > > Exchange completion thread starts waits for 1 seconds before it can signal exchange to compete ? the complete signal will be thus invoked sometime after 1 second depending on OS thread scheduling > > Main thread continues and invokes a stop which has a max wait time of 5 seconds for extant exchanges to complete ? so max completion time of stop is 5 seconds ++ i.e. could be slightly longer than 5 seconds again subject to OS scheduling > > Temporal condition imposed by test > > // The shutdown should take at least as long as the exchange duration > if (elapsed < exchangeDuration.toNanos()) { > fail("HttpServer.stop terminated before exchange completed"); > } > > // The delay should not have expired > if (elapsed >= delayDuration.toNanos()) { > fail("HttpServer.stop terminated after delay expired"); > } > > 1. States elapsed time of stop should be less than the duration of the exchange exchangeDuration. BUT exchangeDuration is not the > duration of the exchange completion. Rather, it is the time delay before the exchange thread is signalled to complete. > The actual completion of the exchange may be sometime later, again depending on OS thread scheduling. > > Second condition is that the elapsed time of the stop should be less than or equal to the stop delay. BUT if the full timeout for the > stop expires as per > > server.stop will wait a max of N (5) seconds before terminating as per > > try { > // waiting for the duration of the delay, unless released before > finishedLatch.await(delay, TimeUnit.SECONDS); > > } catch (InterruptedExceptio... @msheppar @dfuch thanks for the review! I believe it should be fixed in the latest commit ------------- PR Comment: https://git.openjdk.org/jdk/pull/27670#issuecomment-3389904485 From duke at openjdk.org Fri Oct 10 13:25:32 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 13:25:32 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 10:14:03 GMT, Michael McMahon wrote: > 103 103 is for http2, and a lot of clients won't even accept it if the connection is not on http2 > If it's the response headers returned from getResponseHeaders then is this map cleared after the intermediate response or is the user supposed to clear it? Does this work? alright going back to 101 for a second, there is no difficulty, as the 101 _is_ the final response with the final headers, rather than other codes. I can toss this PR and get back exclusively to 101 if we decide the effects for 100-continue are undesirable. > If we are supporting 100 Continue now (under user control) does the expected behavior work? If a client sends a request with an Expect: 100-Continue header and waits for the intermediate response before sending the request body, does this actually work? We removed that behavior from this PR, but while it was in here ([4b00588](https://github.com/openjdk/jdk/pull/27069/commits/4b0058886cf10b1703426acc4131453c46636645#diff-04936de6755028a0d5eb76804c124f811dca641818ef59a2201566d01c3c1441R163-R167)), it worked as expected, the client waited for the manually sent 100 code to send the body and everything. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390079283 From duke at openjdk.org Fri Oct 10 13:36:47 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 13:36:47 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 13:22:44 GMT, Josiah Noel wrote: > We removed that behavior from this PR @Michael-Mc-Mahon just to give a recap, right now this PR doesn't allow control over 100-continue, it just allows you to send extra superfluous 100 (because the current logic where we auto-send 100 continue before the handler is still intact). It was determined that moving the auto continue logic to when the inputstream is read should be evaluated as a separate issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390154639 From duke at openjdk.org Fri Oct 10 13:39:50 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 13:39:50 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 13:22:44 GMT, Josiah Noel wrote: > If it's the response headers returned from getResponseHeaders then is this map cleared after the intermediate response or is the user supposed to clear it? Does this work? It works either way, but clearing I feel is unexpected and undesirable ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390171139 From duke at openjdk.org Fri Oct 10 14:35:05 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 14:35:05 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel 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 It occurs to me, that there is actually no practical reason for this PR. For the 100-continue case, there are better ways to handle it than `sendResponseHeaders` or even a new public `sendIntermediateResponse` method. The best method I think would be to be like jetty and move the auto-send-continue logic to when the inputstream is read. This is because trying to read the input stream implies that you're okay to receive the body. For connection upgrades, this PR is also unrelated as besides keeping the inputstream open, it otherwise behaves like other status codes and doesn't require sending 101 and then some other status. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390488501 From dfuchs at openjdk.org Fri Oct 10 15:45:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 15:45:49 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel 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 I'm personally OK of adding a new API to send 1xx response. WRT 100 I'm a bit of two minds with how to handle that. We heavily use the HttpServer to test the HttpClient HTTP/1.1 stack. In the Httpclient, we wanted to test that if the server didn't send 100, the client would send the body after a reasonable timeout. Then we wanted to test that the 100 would be ignored if it came after the client had started to send the body. We also wanted to test that additional 100 would be ignored. At the moment we need to use a ServerSocket on the server side to do that for HTTP/1.1 because the HttpServer doesn't offer this level of granularity. Adding auto-send in `getRequestBody().read()` would not allow us to use the server to do that either. Another thing we wanted to test is that the client would ignore 1xx code it does not know how to handle. I was hopping that a method to send informational response codes (wether with `sendResponseHeaders` or with a new API) would help us with testing these various scenarios. At the same time - we want our API to be as user friendly as possible - so ability to use the server to test complex scenarios for the benefit of the client comes second. Though equally, maybe other people use our server to test their own client implementations? So that's to explain where I'm coming from. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390825091 From duke at openjdk.org Fri Oct 10 15:51:38 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 15:51:38 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 15:38:58 GMT, Daniel Fuchs wrote: > We heavily use the HttpServer to test the HttpClient HTTP/1.1 stack. In the Httpclient, we wanted to test that if the server didn't send 100, the client would send the body after a reasonable timeout. Then we wanted to test that the 100 would be ignored if it came after the client had started to send the body. We also wanted to test that additional 100 would be ignored. Adding auto-send in `getRequestBody().read()` allows this though? put a sleep in the handler before `getRequestBody().read()`. You have control if/when the 100 is sent, no new public method required. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390863439 From dfuchs at openjdk.org Fri Oct 10 16:01:50 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 16:01:50 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: <45BQXtpPweWXTy2FWk7BlOY9Jvd70v_S5kHHT94V4dA=.d53b10c8-d24e-4c6e-b136-b1608b6abeb1@github.com> On Fri, 10 Oct 2025 15:46:47 GMT, Josiah Noel wrote: > Adding auto-send in getRequestBody().read() allows this though? put a sleep in the handler before getRequestBody().read(). You have control if/when the 100 is sent, no new public method required. The way we would do this with our HTTP/2 test server is to consume the first byte of the request body before sending 100, so as not send 100 before having received the first byte of the body. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390930387 From duke at openjdk.org Fri Oct 10 16:08:06 2025 From: duke at openjdk.org (robert engels) Date: Fri, 10 Oct 2025 16:08:06 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: <45BQXtpPweWXTy2FWk7BlOY9Jvd70v_S5kHHT94V4dA=.d53b10c8-d24e-4c6e-b136-b1608b6abeb1@github.com> References: <45BQXtpPweWXTy2FWk7BlOY9Jvd70v_S5kHHT94V4dA=.d53b10c8-d24e-4c6e-b136-b1608b6abeb1@github.com> Message-ID: On Fri, 10 Oct 2025 15:59:25 GMT, Daniel Fuchs wrote: > The way we would do this with our HTTP/2 test server is to consume the first byte of the request body before sending 100 That is invalid. The whole purpose is to enable the client to avoid sending the request body until the 100 Continue is received (i.e all headers validated by the handler). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390958885 From duke at openjdk.org Fri Oct 10 16:13:12 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 16:13:12 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: <45BQXtpPweWXTy2FWk7BlOY9Jvd70v_S5kHHT94V4dA=.d53b10c8-d24e-4c6e-b136-b1608b6abeb1@github.com> Message-ID: On Fri, 10 Oct 2025 16:05:19 GMT, robert engels wrote: > That is invalid. The whole purpose is to enable the client to avoid sending the request body until the 100 Continue is received (i.e all headers validated by the handler). they're testing the client not the server, but it is a bit strange indeed since the client is already in the process of sending the body. > Another thing we wanted to test is that the client would ignore 1xx code it does not know how to handle. You can send 1xx codes today with sendResponseHeaders, the only caveat is that you can't read the InputStream anymore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390980406 From dfuchs at openjdk.org Fri Oct 10 16:33:46 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 16:33:46 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: <45BQXtpPweWXTy2FWk7BlOY9Jvd70v_S5kHHT94V4dA=.d53b10c8-d24e-4c6e-b136-b1608b6abeb1@github.com> Message-ID: On Fri, 10 Oct 2025 16:10:08 GMT, Josiah Noel wrote: > That is invalid. The whole purpose is to enable the client to avoid sending the request body until the 100 Continue is received (i.e all headers validated by the handler). Well - this is a test server - and it's useful to be able to do "invalid" things in order to test how the client reacts. And note that this is not strictly invalid, since from the client standpoint - it looks exactly the same as if the handling of the request had been delayed on the server side. The client has no way to know that the server has consumed the first byte. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391076880 From duke at openjdk.org Fri Oct 10 16:41:59 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 16:41:59 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel 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 In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391109508 From dfuchs at openjdk.org Fri Oct 10 16:46:48 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 16:46:48 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:37:26 GMT, Josiah Noel wrote: > In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation True. But it would at least allow us to test that status code `123` is properly discarded. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391137340 From duke at openjdk.org Fri Oct 10 16:46:48 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 16:46:48 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:42:42 GMT, Daniel Fuchs wrote: > True. But it would at least allow us to test that status code 123 is properly discarded. you can do this now: `exchange.sendResponseHeaders(123, contentlength)` ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391144932 From duke at openjdk.org Fri Oct 10 16:54:35 2025 From: duke at openjdk.org (robert engels) Date: Fri, 10 Oct 2025 16:54:35 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:42:42 GMT, Daniel Fuchs wrote: >> In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation > >> In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation > > True. But it would at least allow us to test that status code `123` is properly discarded. @dfuch it is invalid in the client, the client if it sets the Expect 100-Continue should not send the body until it receives the 100 Continue. See the rfc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391184328 From duke at openjdk.org Fri Oct 10 16:54:36 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 16:54:36 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:42:42 GMT, Daniel Fuchs wrote: >> In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation > >> In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation > > True. But it would at least allow us to test that status code `123` is properly discarded. > @dfuch it is invalid in the client, the client if it sets the Expect 100-Continue should not send the body until it receives the 100 Continue. See the rfc. okay they should but the rfc also allows for the client to send the body before receiving 100 because servers might ignore the Expect header ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391190551 From duke at openjdk.org Fri Oct 10 17:06:14 2025 From: duke at openjdk.org (robert engels) Date: Fri, 10 Oct 2025 17:06:14 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:52:12 GMT, Josiah Noel wrote: >>> In any case, no matter what option we go with to support 100-continue the automatic sending logic present now will have to be moved/modified as adding a new method doesn't change the fact that 100-continue is being sent before handlers are called. Perhaps we should focus more on that part before we add new methods that don't actually change the situation >> >> True. But it would at least allow us to test that status code `123` is properly discarded. > >> @dfuch it is invalid in the client, the client if it sets the Expect 100-Continue should not send the body until it receives the 100 Continue. See the rfc. > > okay they should but the rfc also allows for the client to send the body before receiving 100 because servers might ignore the Expect header @SentryMan you are correct. The rfc confirms it - sorry for the noise @dfuch ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391246481 From dfuchs at openjdk.org Fri Oct 10 17:18:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 17:18:00 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 16:43:58 GMT, Josiah Noel wrote: > you can do this now: `exchange.sendResponseHeaders(123, -1)` You mean - with the changes in your PR? Because without these changes I suspect you might have to pass 0, not -1. So pretend that there is a body of unknown length. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391309715 From duke at openjdk.org Fri Oct 10 17:23:44 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 17:23:44 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: <3G3ywMmx0JdxDhLRti-5EfmCv4RXDWz5SJLJpzWvPAA=.a0bf68d2-4ab8-41d2-8043-b16178171daa@github.com> On Fri, 10 Oct 2025 17:15:24 GMT, Daniel Fuchs wrote: > Because without these changes I suspect you might have to pass 0, not -1. So pretend that there is a body of unknown length. without the changes it's treated like a response without a body, so 0/-1 doesn't matter as it will be overridden ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3391345379 From dfuchs at openjdk.org Fri Oct 10 17:37:21 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 10 Oct 2025 17:37:21 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> Message-ID: <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> On Fri, 10 Oct 2025 12:50:42 GMT, Mikhail Yankelevich 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). > > Mikhail Yankelevich 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 four additional commits since the last revision: > > - race condition fix > - Merge branch 'master' into JDK-8368625 > - race condition fix > - JDK-8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 127: > 125: // Complete the exchange one second into the future > 126: final Duration exchangeDuration = Duration.ofSeconds(1); > 127: final long startTime = System.nanoTime(); // taking custom start time just in case Suggestion: // taking start time before entering completeExchange to account for possible // delays in reaching server.stop(). final long startTime = System.nanoTime(); test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 164: > 162: // Complete the exchange 10 second into the future. > 163: // Runs in parallel, so won't block the server stop > 164: final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(10)); Looks good, but if this test fail we could envisage bumping that delay though. A better implementation could be to complete the exchange *after* exiting from server.stop() - without using any virtual thread, and just verifying that the server.stop() waited at least for 1s. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2421333349 PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2421380885 From duke at openjdk.org Fri Oct 10 20:15:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 20:15:02 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver Message-ID: - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` ------------- Commit messages: - Update SwitchingProtocolTest.java - Create UpgradeInputStream.java - Delete UpgradeInputStream.java - Support 101 upgrade requests Changes: https://git.openjdk.org/jdk/pull/27751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368695 Stats: 278 lines in 3 files changed: 270 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From djelinski at openjdk.org Fri Oct 10 20:18:38 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 10 Oct 2025 20:18:38 GMT Subject: RFR: 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out Message-ID: The first test case in H3MalformedResponseTest is still intermittently failing with TimeoutException, even after #27447. This PR removes the unnecessary per-request time limit. ------------- Commit messages: - Remove request timeout Changes: https://git.openjdk.org/jdk/pull/27752/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27752&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369593 Stats: 13 lines in 1 file changed: 0 ins; 7 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27752.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27752/head:pull/27752 PR: https://git.openjdk.org/jdk/pull/27752 From duke at openjdk.org Fri Oct 10 20:50:25 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 20:50:25 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v2] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update UpgradeInputStream.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/8b68230c..d3835941 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=00-01 Stats: 45 lines in 1 file changed: 45 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Fri Oct 10 21:22:49 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 10 Oct 2025 21:22:49 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update UpgradeInputStream.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/d3835941..ee8b2bcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From jpai at openjdk.org Sun Oct 12 11:09:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 12 Oct 2025 11:09:07 GMT Subject: RFR: 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 20:11:41 GMT, Daniel Jeli?ski wrote: > The first test case in H3MalformedResponseTest is still intermittently failing with TimeoutException, even after #27447. This PR removes the unnecessary per-request time limit. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27752#pullrequestreview-3328142567 From jpai at openjdk.org Mon Oct 13 05:20:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Oct 2025 05:20:46 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v6] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Volkan's review - add a comment in test - merge latest from master branch - Daniel's suggestion - add reachability fence - Volkan's review - merge latest from master branch - Daniel's suggestion - don't repeat/copy code from super() - merge latest from master branch - missed pushing the change - 8367561: fix inputstream leak - 8367561: introduce tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/0f23e390..75429696 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=04-05 Stats: 5836 lines in 165 files changed: 4202 ins; 1087 del; 547 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Mon Oct 13 05:20:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Oct 2025 05:20:47 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: On Wed, 8 Oct 2025 15:54:53 GMT, Volkan Yazici wrote: >>> If I'm not mistaken at least FileInputStream has a cleaner to close its file descriptor: >>> >>> https://github.com/openjdk/jdk/blob/23fcbb0badbef6d22f63ca6c5b26b0693002592c/src/java.base/share/classes/java/io/FileInputStream.java#L140 >> >> >> You are right indeed - I have stared at that constructor code for several minutes but hadn't spotted this. I had additionally done a text search for "cleaner" in that class and only found their references in the javadoc text. Thank you for catching this. GC could indeed have played a role here. > > This is a very subtle detail, shall we document the rationale for `Reference.reachabilityFence(conn)`? Hello Volkan, I've now added a comment in the test methods to explain why this line is present. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2425235121 From jpai at openjdk.org Mon Oct 13 05:25:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 13 Oct 2025 05:25:07 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v5] In-Reply-To: References: Message-ID: <3GCgq-Zb_bJzrF5Qw7VZFwJvk_3enW8VOP_JoAiPupo=.50798347-d464-4e9c-af73-1dad5efaa73b@github.com> On Wed, 8 Oct 2025 16:03:02 GMT, Volkan Yazici wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Daniel's suggestion - add reachability fence > > test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 1: > >> 1: /* > > Converting this entire class to a single `@ParameterizedTest` method (i.e., no instance field, no `@{Before,After}Each`) can avoid significant duplication. > > > @ParameterizedTest("connTesters") > void test(Consumer connTester) { > Path file = Files.createTempFile(Path.of("."), "8367561-", ".txt"); > try { > Files.writeString(file, String.valueOf(System.currentTimeMillis())); > URLConnection conn = file.toUri().toURL().openConnection(); > assertNotNull(conn, "URLConnection for " + file + " is null"); > assertEquals(FILE_URLCONNECTION_CLASSNAME, conn.getClass().getName(), > "unexpected URLConnection type"); > connTester.accept(conn); > Reference.reachabilityFence(conn); > } finally { > Files.deleteIfExists(file); > } > } In my initial experiments I had considered this idea, but I decided to use the present form because it allows me to add additional asserts for some of the API calls more closer in the test method itself, than in the centralized code where the parameters are built for the ParameterizedTest. I prefer the present form even if it means repetition of some test code. Would that be OK? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2425240093 From vyazici at openjdk.org Mon Oct 13 07:07:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 13 Oct 2025 07:07:12 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v5] In-Reply-To: <3GCgq-Zb_bJzrF5Qw7VZFwJvk_3enW8VOP_JoAiPupo=.50798347-d464-4e9c-af73-1dad5efaa73b@github.com> References: <3GCgq-Zb_bJzrF5Qw7VZFwJvk_3enW8VOP_JoAiPupo=.50798347-d464-4e9c-af73-1dad5efaa73b@github.com> Message-ID: <_9Rjf-ilSpNpR_YM3UcRvv1sb_xwwAT_uJMtwiXeuRg=.54a2aa20-e486-4af1-a255-f22097f58c61@github.com> On Mon, 13 Oct 2025 05:21:59 GMT, Jaikiran Pai wrote: >> test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 1: >> >>> 1: /* >> >> Converting this entire class to a single `@ParameterizedTest` method (i.e., no instance field, no `@{Before,After}Each`) can avoid significant duplication. >> >> >> @ParameterizedTest("connTesters") >> void test(Consumer connTester) { >> Path file = Files.createTempFile(Path.of("."), "8367561-", ".txt"); >> try { >> Files.writeString(file, String.valueOf(System.currentTimeMillis())); >> URLConnection conn = file.toUri().toURL().openConnection(); >> assertNotNull(conn, "URLConnection for " + file + " is null"); >> assertEquals(FILE_URLCONNECTION_CLASSNAME, conn.getClass().getName(), >> "unexpected URLConnection type"); >> connTester.accept(conn); >> Reference.reachabilityFence(conn); >> } finally { >> Files.deleteIfExists(file); >> } >> } > > In my initial experiments I had considered this idea, but I decided to use the present form because it allows me to add additional asserts for some of the API calls more closer in the test method itself, than in the centralized code where the parameters are built for the ParameterizedTest. > > I prefer the present form even if it means repetition of some test code. Would that be OK? Perfectly fine. ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2425376530 From vyazici at openjdk.org Mon Oct 13 07:34:05 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 13 Oct 2025 07:34:05 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 12:04:28 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Add test explicitly setting content length to zero test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 217: > 215: assertEquals(resp.statusCode(), 200, resp.body()); > 216: assertEquals(resp.version(), version); > 217: assertEquals(resp.body(), "Request completed"); If possible, you may consider verifying the response body in other test methods too, since, in particular, `OptionalContentLengthHandler` responds with 200 in two different scenarios. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2425435656 From vyazici at openjdk.org Mon Oct 13 07:43:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 13 Oct 2025 07:43:02 GMT Subject: RFR: 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 20:11:41 GMT, Daniel Jeli?ski wrote: > The first test case in H3MalformedResponseTest is still intermittently failing with TimeoutException, even after #27447. This PR removes the unnecessary per-request time limit. I had [approved this] 3 weeks ago. ? [approved this]: https://github.com/openjdk/jdk/pull/27447/files/16d6b3e2cf55059150d5e97f877166eb777a5714#r2371562116 ------------- Marked as reviewed by vyazici (Committer). PR Review: https://git.openjdk.org/jdk/pull/27752#pullrequestreview-3330313876 From michaelm at openjdk.org Mon Oct 13 09:57:08 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 13 Oct 2025 09:57:08 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: <14q1kktwg0rrHKP_V9AZpGuYqT-TFsLrHb9wyb_Rkfc=.15b6b6c0-4815-4025-8ad0-36798c5343ec@github.com> On Fri, 10 Oct 2025 14:31:24 GMT, Josiah Noel wrote: > It occurs to me, that there is actually no practical reason for this PR. For the 100-continue case, there are better ways to handle it than `sendResponseHeaders` or even a new public `sendIntermediateResponse` method. The best method I think would be to be like jetty and move the auto-send-continue logic to when the inputstream is read. This is because trying to read the input stream implies that you're okay to receive the body. > > For connection upgrades, this PR is also unrelated as besides keeping the inputstream open, it otherwise behaves like other status codes and doesn't require sending 101 and then some other status. Possibly. If we are agreed that 100 Continue is the only potential practical use case for this (other than 101 which is out of scope), then we definitely don't need a new method at this time, and we then need to ask what point is there in sending a 100 Continue considering that the server already handles it. Is there a use case for allowing the user to send it separately? If not, I'm questioning the benefit of allowing it. As I said from the start, this was never intended to be supported in the initial implementation and my first thought was just to disallow it formally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3396710368 From vyazici at openjdk.org Mon Oct 13 10:11:07 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 13 Oct 2025 10:11:07 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 12:04:28 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Add test explicitly setting content length to zero ### Why is this an HTTP/1.1-only problem? HTTP/2 and HTTP/3 implementations of `HttpClient` already add the `Content-Length` header iff it is greater than zero: https://github.com/openjdk/jdk/blob/4728f746a89ca7cb787b3d9969f09a80cc92f502/src/java.net.http/share/classes/jdk/internal/net/http/Stream.java#L906-L908 https://github.com/openjdk/jdk/blob/4728f746a89ca7cb787b3d9969f09a80cc92f502/src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java#L388-L390 They do this, unlike the `POST` and `PUT` exemption for HTTP/1.1 in the proposed PR, for all methods. This behavior difference between HTTP/1 and HTTP/{2,3} is not a problem because 1. HTTP/2 and HTTP/3 are implicitly chunked when `Content-Length` is missing. 2. `Content-Length` is always optional for HTTP/2 and HTTP/3, for all methods. A user agent may add it, in which case it must match the total number of bytes sent in the body request. **Credits:** Thanks to @dfuch and @djelinski for patiently answering my questions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27727#issuecomment-3396762951 From michaelm at openjdk.org Mon Oct 13 10:13:21 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 13 Oct 2025 10:13:21 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> Message-ID: On Wed, 8 Oct 2025 16:53:13 GMT, Josiah Noel wrote: >> @AlanBateman I hadn't realised that the HttpServer didn't already have access to `sun.net.*` - and I agree that it would be better if we did not add such an access. That said - the new property is a compatibility property - and documenting in module-info seemed a bit too much - so out of the way in `net.properties` seemed like an appealing place to add it. >> >> Another possibility could be to document it only in the release notes. > > Shall I revert the change and leave as a system property? Could we get access to net.properties without needing to use that class in sun.net? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2425807256 From alanb at openjdk.org Mon Oct 13 10:22:47 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 13 Oct 2025 10:22:47 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> Message-ID: On Mon, 13 Oct 2025 10:10:59 GMT, Michael McMahon wrote: > Could we get access to net.properties without needing to use that class in sun.net? net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2425836895 From michaelm at openjdk.org Mon Oct 13 10:40:04 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 13 Oct 2025 10:40:04 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> Message-ID: On Mon, 13 Oct 2025 10:20:31 GMT, Alan Bateman wrote: > > Could we get access to net.properties without needing to use that class in sun.net? > > net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource. I guess it still means duplicating the NetProperties class in jdk.httpserver, which might not be too desirable. Or alternatively create a httpserver specific properties file. Not sure it's worth all that effort unless other properties might migrate there also. Otherwise, we can revert to a simple system property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2425891383 From dfuchs at openjdk.org Mon Oct 13 11:18:07 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 11:18:07 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: Message-ID: <-aHZ14Rd5aEuULVg2PLCGBG6nyXizfNgFmcw9Lwzy3E=.796e0014-b963-4afd-8aa3-4c4917f8c5ba@github.com> On Mon, 13 Oct 2025 05:17:06 GMT, Jaikiran Pai wrote: >> This is a very subtle detail, shall we document the rationale for `Reference.reachabilityFence(conn)`? > > Hello Volkan, I've now added a comment in the test methods to explain why this line is present. Technically the reachabilityFence should be in the finally clause of a try-finally to make sure it's not rearranged away by JIT - but I'm not sure how important this is for a test like this. Alternative could be to stash the reference in a static field. As long as the test methods are not run in parallel that should work too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2426003503 From dfuchs at openjdk.org Mon Oct 13 11:18:07 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 11:18:07 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: <-aHZ14Rd5aEuULVg2PLCGBG6nyXizfNgFmcw9Lwzy3E=.796e0014-b963-4afd-8aa3-4c4917f8c5ba@github.com> References: <-aHZ14Rd5aEuULVg2PLCGBG6nyXizfNgFmcw9Lwzy3E=.796e0014-b963-4afd-8aa3-4c4917f8c5ba@github.com> Message-ID: On Mon, 13 Oct 2025 11:15:16 GMT, Daniel Fuchs wrote: >> Hello Volkan, I've now added a comment in the test methods to explain why this line is present. > > Technically the reachabilityFence should be in the finally clause of a try-finally to make sure it's not rearranged away by JIT - but I'm not sure how important this is for a test like this. Alternative could be to stash the reference in a static field. As long as the test methods are not run in parallel that should work too. Otherwise LGTM ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2426004480 From dfuchs at openjdk.org Mon Oct 13 11:32:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 11:32:06 GMT Subject: RFR: 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 20:11:41 GMT, Daniel Jeli?ski wrote: > The first test case in H3MalformedResponseTest is still intermittently failing with TimeoutException, even after #27447. This PR removes the unnecessary per-request time limit. Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27752#pullrequestreview-3331205342 From dfuchs at openjdk.org Mon Oct 13 12:55:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 12:55:49 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: <6svwQgyoJZUJnOT1YuMVlUUTZvDdc9X4qRTBL_i-M14=.2b4f7ccf-4e5b-4f5b-99bf-872184958690@github.com> On Fri, 10 Oct 2025 12:04:28 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Add test explicitly setting content length to zero Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27727#pullrequestreview-3331517205 From dfuchs at openjdk.org Mon Oct 13 12:59:49 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 12:59:49 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v5] In-Reply-To: References: <13v-R4-JQDyFKqMlXaMfu-RgXdxL0h2z1InXGb0inyk=.6f2c296a-6d94-4688-953e-cab3d8dac141@github.com> <_7C7kivl1GlzjlnfVGIjzBJLzIiUrQlgfA88zkHvPqY=.2672c6c7-27c0-47d5-b03b-8f0001e22e26@github.com> Message-ID: On Mon, 13 Oct 2025 10:37:47 GMT, Michael McMahon wrote: >>> Could we get access to net.properties without needing to use that class in sun.net? >> >> net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource. > >> > Could we get access to net.properties without needing to use that class in sun.net? >> >> net.properties is user editable configuration (in ${java.home}/conf), it's not an encapsulated resource. > > I guess it still means duplicating the NetProperties class in jdk.httpserver, which might not be too desirable. Or alternatively create a httpserver specific properties file. Not sure it's worth all that effort unless other properties might migrate there also. Otherwise, we can revert to a simple system property. +1 for reverting to a simple system property. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426274101 From dfuchs at openjdk.org Mon Oct 13 13:05:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 13:05:54 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel 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 If we're not going to allow `sendResponseHeaders` to accept `1xx` codes then I believe we should modify it to throw if a `1xx` status code is passed, and document that formally in the API documentation of the method, rather than have the implementation send `1xx` as a final response. Maybe this PR should do that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3397448910 From duke at openjdk.org Mon Oct 13 13:50:10 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 13:50:10 GMT Subject: RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21] In-Reply-To: <14q1kktwg0rrHKP_V9AZpGuYqT-TFsLrHb9wyb_Rkfc=.15b6b6c0-4815-4025-8ad0-36798c5343ec@github.com> References: <14q1kktwg0rrHKP_V9AZpGuYqT-TFsLrHb9wyb_Rkfc=.15b6b6c0-4815-4025-8ad0-36798c5343ec@github.com> Message-ID: On Mon, 13 Oct 2025 09:54:31 GMT, Michael McMahon wrote: > Possibly. If we are agreed that 100 Continue is the only potential practical use case for this as the PR stands now, even that is no longer relevant, because of the auto-send. We are in one accord then that this PR implementation does not have anything of worth. > Continue considering that the server already handles it. Is there a use case for allowing the user to send it separately? Given that the server automatically sends 100-Continue without allowing the handler to validate if the body should be sent, I think we should make a different PR delaying the auto send until `getRequestBody().read()`. This would allow for proper 100 continue behavior where the server only continues the request if the request is validated. > If we're not going to allow sendResponseHeaders to accept 1xx codes I'm amenable to banning 100 (because the server handles it) and 103 (needs http2), but once again I ask for a discussion on http 101 before we proceed to say that all 1xx codes are not accepted. I've created #27751 for review and a place to discuss, would you kindly take a moment to review and voice your concerns? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3397611795 From duke at openjdk.org Mon Oct 13 13:56:21 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 13:56:21 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v6] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: System property once more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/7711d93c..9a971fe4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=04-05 Stats: 12 lines in 3 files changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From dfuchs at openjdk.org Mon Oct 13 14:17:12 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 14:17:12 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v6] In-Reply-To: References: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> Message-ID: On Wed, 8 Oct 2025 12:53:48 GMT, Daniel Fuchs wrote: >> Yeah, I think we should put the property in `net.properties` something like this: >> >> >> # Prior to JDK 26, the HttpExchange attribute map was shared with the enclosing HttpContext. >> # Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must >> # be accessed by calling getHttpContext().getAttributes(). Uncomment this property to >> # restore the pre JDK 26 behavior. >> # >> # jdk.httpserver.attributes=context >> >> Then I think we should add a sentence at the end of the jdk.httpserver module-info to say that additional >> system/networking properties may be defined in `net.properties` > > That proposal sounds good to me. Documenting the compatibiity in net.properties makes sense. When talking with Michael he suggested that we could document the new property at the bottom of the module-info, in a new section dedicated to compatibility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426483886 From duke at openjdk.org Mon Oct 13 14:23:39 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 14:23:39 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v7] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: doc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/9a971fe4..099d7652 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=05-06 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From dfuchs at openjdk.org Mon Oct 13 15:18:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 15:18:45 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v7] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 14:23:39 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > doc src/jdk.httpserver/share/classes/module-info.java line 108: > 106: * be accessed by calling getHttpContext().getAttributes(). Set this property to "context" > 107: * to restore the pre JDK 26 behavior. > 108: * I would suggest to move that to an `@implNote` - something like: Suggestion: * * * @implNote * Prior to JDK 26, in the JDK default implementation, the {@link HttpExchange} attribute map was * shared with the enclosing {@link HttpContext}. * Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()} * {@link HttpContext#getAttributes() HttpContext.getAttributes()}.
* A new system property, {@systemProperty jdk.httpserver.attributes} (default value: {@code ""}) * allows to revert this new behavior. Set this property to "context" to restore the pre JDK 26 behavior. * @Michael-Mc-Mahon what do you think? (@SentryMan please double check whether some package should imported - or the `{@link }` modified to use full pacakage names for the links to work properly in the generated API doc) src/jdk.httpserver/share/classes/module-info.java line 111: > 109: * > 110: * Additional system/networking properties may be defined in the {@code conf/net.properties} configuration file. > 111: * @Michael-Mc-Mahon should we keep that paragraph? It looks like it could be removed now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426635214 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426600519 From michaelm at openjdk.org Mon Oct 13 15:32:35 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Mon, 13 Oct 2025 15:32:35 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 21:22:49 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update UpgradeInputStream.java Is the intention behind this to support websocket? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3397996842 From duke at openjdk.org Mon Oct 13 15:50:37 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 15:50:37 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 15:29:32 GMT, Michael McMahon wrote: > Is the intention behind this to support websocket? To speak plainly, my plan is not for adding official websocket support into the JDK. That part I can do on my own, the only thing I lack is access to the input/output streams after sending a 101 code. (the current logic in send headers closes both after sending 101 headers) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3398067890 From duke at openjdk.org Mon Oct 13 16:05:16 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 16:05:16 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v8] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: implnote ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/099d7652..2880dffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=06-07 Stats: 16 lines in 1 file changed: 9 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Mon Oct 13 16:10:04 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 16:10:04 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 21:22:49 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update UpgradeInputStream.java Don't get me wrong though, if you guys decide you want to fully support websocket, I'll gladly offer a PR. (But I highly doubt such a thing will happen) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3398140406 From dfuchs at openjdk.org Mon Oct 13 16:13:12 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 16:13:12 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 21:22:49 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update UpgradeInputStream.java src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 172: > 170: if (upgrade) { > 171: uis_orig = new UpgradeInputStream(this, ris); > 172: } else if (reqContentLen == -1L) { Are we sure that `upgrade` and `reqConteLength != 0` are always exclusive? IIRC this is not the case for the HTTP/2 upgrade. The request body (if present) is sent through HTTP/1.1 and only after that is the connection upgraded to HTTP/2 - if the upgrade is accepted. Also the handler could very well ignore the upgrade and continue with HTTP/1.1. It seems we need more discussion on whether we should support connection upgrade and what kind of API would be needed for that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27751#discussion_r2426749626 From dfuchs at openjdk.org Mon Oct 13 16:27:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 16:27:03 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v8] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 16:05:16 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > implnote src/jdk.httpserver/share/classes/module-info.java line 111: > 109: * Since JDK 26, by default, exchange attributes are per-exchange and the context attributes must > 110: * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()} > 111: * {@link HttpContext#getAttributes() HttpContext.getAttributes()}.
Suggestion: * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()}{@link * HttpContext#getAttributes() .getAttributes()}.
Sorry, there was a mistake in my previous suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2426798503 From duke at openjdk.org Mon Oct 13 16:32:24 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 16:32:24 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v9] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update module-info.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/2880dffc..1164702a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Mon Oct 13 16:34:47 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 16:34:47 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 16:02:28 GMT, Daniel Fuchs wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update UpgradeInputStream.java > > src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 172: > >> 170: if (upgrade) { >> 171: uis_orig = new UpgradeInputStream(this, ris); >> 172: } else if (reqContentLen == -1L) { > > Are we sure that `upgrade` and `reqConteLength != 0` are always exclusive? IIRC this is not the case for the HTTP/2 upgrade. The request body (if present) is sent through HTTP/1.1 and only after that is the connection upgraded to HTTP/2 - if the upgrade is accepted. Also the handler could very well ignore the upgrade and continue with HTTP/1.1. > > It seems we need more discussion on whether we should support connection upgrade and what kind of API would be needed for that. GET requests usually don't have bodies ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27751#discussion_r2426811348 From dfuchs at openjdk.org Mon Oct 13 16:34:48 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 13 Oct 2025 16:34:48 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: <81QSPDJt4zuo8_6nXA_l6xGS26br-3NHr6NfSoqs38A=.f5381bd4-da70-4846-9d21-5f479991b5c0@github.com> On Mon, 13 Oct 2025 16:29:50 GMT, Josiah Noel wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 172: >> >>> 170: if (upgrade) { >>> 171: uis_orig = new UpgradeInputStream(this, ris); >>> 172: } else if (reqContentLen == -1L) { >> >> Are we sure that `upgrade` and `reqConteLength != 0` are always exclusive? IIRC this is not the case for the HTTP/2 upgrade. The request body (if present) is sent through HTTP/1.1 and only after that is the connection upgraded to HTTP/2 - if the upgrade is accepted. Also the handler could very well ignore the upgrade and continue with HTTP/1.1. >> >> It seems we need more discussion on whether we should support connection upgrade and what kind of API would be needed for that. > > GET requests usually don't have bodies But does upgrade require GET? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27751#discussion_r2426816218 From duke at openjdk.org Mon Oct 13 16:53:41 2025 From: duke at openjdk.org (Josiah Noel) Date: Mon, 13 Oct 2025 16:53:41 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: <81QSPDJt4zuo8_6nXA_l6xGS26br-3NHr6NfSoqs38A=.f5381bd4-da70-4846-9d21-5f479991b5c0@github.com> References: <81QSPDJt4zuo8_6nXA_l6xGS26br-3NHr6NfSoqs38A=.f5381bd4-da70-4846-9d21-5f479991b5c0@github.com> Message-ID: On Mon, 13 Oct 2025 16:32:27 GMT, Daniel Fuchs wrote: >> GET requests usually don't have bodies > > But does upgrade require GET? Every example I see in online and in the RFC shows a GET method, but you are correct in that the [RFC does not appear to forbid non-GET methods](https://www.rfc-editor.org/rfc/rfc9110.html#name-upgrade). WebSockets exclusively use GET though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27751#discussion_r2426850952 From vyazici at openjdk.org Tue Oct 14 09:43:06 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 14 Oct 2025 09:43:06 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync Message-ID: Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. `tier1-2` passes with the proposed changes. **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 ------------- Commit messages: - Document exception wrapping in `HttpClientImpl::send` - Fix test failures - Ensure `sendAsync` wraps execution failures in `IOException` Changes: https://git.openjdk.org/jdk/pull/27787/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368249 Stats: 379 lines in 7 files changed: 323 ins; 41 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From vyazici at openjdk.org Tue Oct 14 09:43:09 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 14 Oct 2025 09:43:09 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync In-Reply-To: References: Message-ID: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> On Tue, 14 Oct 2025 07:21:21 GMT, Volkan Yazici wrote: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1147: > 1145: var translatedException = unwrappedException instanceof Error > 1146: ? unwrappedException > 1147: : Utils.toIOException(exception); `toIOException()`, which is _only_ used in `Http3PushManager::cancelPendingPushPromise`, performs unwrapping of `CompletionException` and `ExecutionException` too, though it doesn't exclude `Error`. I considered following approaches: 1. Don't use `toIOException` and hard-code all the translation logic to here 2. Update `toIOException()` to not wrap `Error` ? This implies I need to change method's return type from `IOException` to `Throwable`, and this creates problems at the `cancelPendingPushPromise()` call site, since it uses `Http3PushPromiseStream#cancel(IOException)` (note the required `IOException` argument!), which overrides `ExchangeImpl#cancel(IOException)`. In short, this is a dead end. 3. Specialize on `Error` here, but still use `toIOException()` for the rest. I've implemented the 3rd option. But as time passes, I'm getting inclined towards hard-coding all the translation logic (1st option) *and* move `Utils::toIOException` to `Http3PushManager` as a `private` method. I'd appreciate your thoughts on the matter. test/jdk/java/net/httpclient/HttpClientSendAsyncExceptionTest.java line 173: > 171: testCases.add(new ExceptionTestCase( > 172: "IOException", > 173: _ -> { sneakyThrow(ioException); throw new AssertionError(); }, Sneaky-throw is necessary to throw a checked exception (i.e., `IOException`) from a `HttpResponse.BodyHandler`. test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java line 476: > 474: } > 475: > 476: private static boolean throwableCausalChainContainsInstanceOf( `HttpClientImpl::send` wraps `IOException` (wrapping `IllegalArgumentException`) thrown by `sendAsync` in an `IOException` again. As a result, the existing checks performing _"unwrapping of `IOException` once"_ do not work anymore. Since the existing unwrapping was not strict ? that is, they're not enforced, but optionally unwrapping if types match in the causal chain ? I've further relaxed it with scanning the causal chain. test/jdk/java/net/httpclient/http3/StopSendingTest.java line 184: > 182: } > 183: > 184: private static boolean throwableCausalChainContainsInstanceOf( `HttpClientImpl::send` wraps `IOException` (wrapping `CancellationException`) thrown by `sendAsync` in an `IOException` again. As a result, the existing checks performing _"unwrapping of `IOException` once"_ do not work anymore. Since the existing unwrapping was not strict ? that is, they're not enforced, but optionally unwrapping if types match in the causal chain ? I've further relaxed it with scanning the causal chain. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2428184830 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2428188838 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2428445942 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2428460756 From jpai at openjdk.org Tue Oct 14 09:44:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 09:44:09 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly Message-ID: Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. A new jtreg test has been introduced to reproduce the issue and verify the fix. ------------- Commit messages: - 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly Changes: https://git.openjdk.org/jdk/pull/27793/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369812 Stats: 222 lines in 3 files changed: 215 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27793.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27793/head:pull/27793 PR: https://git.openjdk.org/jdk/pull/27793 From jpai at openjdk.org Tue Oct 14 10:37:36 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 10:37:36 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v7] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Daniel's review, use a class level field for URLConnection ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/75429696..f2938a1b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=05-06 Stats: 218 lines in 1 file changed: 14 ins; 181 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From jpai at openjdk.org Tue Oct 14 10:37:37 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 10:37:37 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v3] In-Reply-To: References: <-aHZ14Rd5aEuULVg2PLCGBG6nyXizfNgFmcw9Lwzy3E=.796e0014-b963-4afd-8aa3-4c4917f8c5ba@github.com> Message-ID: On Mon, 13 Oct 2025 11:15:30 GMT, Daniel Fuchs wrote: >> Technically the reachabilityFence should be in the finally clause of a try-finally to make sure it's not rearranged away by JIT - but I'm not sure how important this is for a test like this. Alternative could be to stash the reference in a static field. As long as the test methods are not run in parallel that should work too. > > Otherwise LGTM I decided to store the `URLConnection` instance as a class level field instead of a try/finally with `Reference.reachabilityFence()` in the finally. With that change, I also decided to use Volkan's suggestion of using a `@ParameterizedTest` for some of these test methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2428678538 From jpai at openjdk.org Tue Oct 14 11:31:24 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 11:31:24 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? > > As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Daniel's suggestion - remove assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27793/files - new: https://git.openjdk.org/jdk/pull/27793/files/7a37f20b..edf3ea42 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27793.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27793/head:pull/27793 PR: https://git.openjdk.org/jdk/pull/27793 From djelinski at openjdk.org Tue Oct 14 12:27:14 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 12:27:14 GMT Subject: RFR: 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out In-Reply-To: References: Message-ID: <-Hmx75ubCWGnwjlNDoROlQ8Mjt2tDHxd2OjVIMqstmk=.de44365b-a85a-4ea0-864b-b4eb8222b9e6@github.com> On Sun, 12 Oct 2025 11:06:24 GMT, Jaikiran Pai wrote: >> The first test case in H3MalformedResponseTest is still intermittently failing with TimeoutException, even after #27447. This PR removes the unnecessary per-request time limit. > > This looks good to me. Thanks @jaikiran @vy @dfuch for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27752#issuecomment-3401526836 From djelinski at openjdk.org Tue Oct 14 12:27:15 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 12:27:15 GMT Subject: Integrated: 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 20:11:41 GMT, Daniel Jeli?ski wrote: > The first test case in H3MalformedResponseTest is still intermittently failing with TimeoutException, even after #27447. This PR removes the unnecessary per-request time limit. This pull request has now been integrated. Changeset: 6d1529cd Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/6d1529cd70718b3c26d65cc54c8a4fb8df06adb7 Stats: 13 lines in 1 file changed: 0 ins; 7 del; 6 mod 8369593: Test H3MalformedResponseTest.testMalformedResponse still times out Reviewed-by: jpai, vyazici, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27752 From djelinski at openjdk.org Tue Oct 14 12:31:15 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 12:31:15 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v2] In-Reply-To: References: Message-ID: <0BfMFy49MWJj7Y-nIVGEgTQjycaQCWmdFo-TIP1vRMc=.a3eafba3-e447-4441-90a5-af66d71b1742@github.com> On Tue, 14 Oct 2025 11:31:24 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's suggestion - remove assert LGTM. Thanks! ------------- Marked as reviewed by djelinski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27793#pullrequestreview-3335353203 From jpai at openjdk.org Tue Oct 14 12:59:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 12:59:16 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? > > As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: forgot to include @bug id in the test definition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27793/files - new: https://git.openjdk.org/jdk/pull/27793/files/edf3ea42..80da00de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27793.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27793/head:pull/27793 PR: https://git.openjdk.org/jdk/pull/27793 From michaelm at openjdk.org Tue Oct 14 13:07:07 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 14 Oct 2025 13:07:07 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 16:07:22 GMT, Josiah Noel wrote: > Don't get me wrong though, if you guys decide you want to fully support websocket, I'll gladly offer a PR. (But I highly doubt such a thing will happen) Right, I don't think we want to support websocket. There are plenty of third party implementations out there and it's a bit too far removed from the purpose as a lightweight server, for serving mainly static content. However, if we were to allow this enabling functionality, it would have to be documented and specified, so that other people could use it. I'd have preferred if the general shape of such an "upgrade API" was discussed on the net-dev email list but we can discuss it here, without prejudice to whether it goes ahead or not. As a minimum, the feature would have to be "opt in" by the handler, probably through a new method on HttpExchange and we have to consider the impact on the rest of the API, such as what happens when HttpServer.stop is called. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3401701954 From duke at openjdk.org Tue Oct 14 13:36:51 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 13:36:51 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: <0Og7PHWsxpCRIwXRFzpyad8_auSyAxOTowBxMJsYlU4=.340610a0-6287-4a2f-97e8-5dc1f728bd99@github.com> On Tue, 14 Oct 2025 13:04:07 GMT, Michael McMahon wrote: > it would have to be documented and specified, so that other people could use it. For me, it was already implied that 101 status could be sent, because the documentation for `sendResponseHeaders` did not even hint that it treats informational responses like 204/304 status codes and closes the streams. No matter what happens, I agree that we should update the documentation. > probably through a new method on HttpExchange For http2 I'm in agreement for a new method, as supporting that kind of upgrade is has far more complexity and requires consuming the body before upgrading. For WebSocket though, such a thing can be accomplished cleanly through the current API. Indeed, in some other implementations of `jdk.httpserver` I'm able to upgrade to websocket with the same API because 101 status was not treated like a 204, and the streams were not closed immediately. > As a minimum, the feature would have to be "opt in" by the handler, Requiring a manual call of `sendResponseHeaders(101, 0)` and the requirement to custom implement the entire protocol appears pretty opt in to me. > we have to consider the impact on the rest of the API, such as what happens when HttpServer.stop is called. Testing locally, calling stop appears to work the same as an extended GET request. What kind of test assertions would you like to see? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3401900691 From dfuchs at openjdk.org Tue Oct 14 13:36:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 13:36:52 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v3] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 12:59:16 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > forgot to include @bug id in the test definition Changes requested by dfuchs (Reviewer). test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java line 150: > 148: .setOption(H3_DISCOVERY, HTTP_3_URI_ONLY) > 149: .uri(new URI(reqURI.toString() + "?iteration=" + i)) > 150: .build(); To make sure the request is retried for the right reasons you might want to switch to POST rather than GET here, as GET may be retried whatever the reset reason. ------------- PR Review: https://git.openjdk.org/jdk/pull/27793#pullrequestreview-3335704803 PR Review Comment: https://git.openjdk.org/jdk/pull/27793#discussion_r2429214876 From duke at openjdk.org Tue Oct 14 13:51:48 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 13:51:48 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: <0Og7PHWsxpCRIwXRFzpyad8_auSyAxOTowBxMJsYlU4=.340610a0-6287-4a2f-97e8-5dc1f728bd99@github.com> References: <0Og7PHWsxpCRIwXRFzpyad8_auSyAxOTowBxMJsYlU4=.340610a0-6287-4a2f-97e8-5dc1f728bd99@github.com> Message-ID: On Tue, 14 Oct 2025 13:33:45 GMT, Josiah Noel wrote: > work the same as an extended GET request. In fact, this might be a good way of thinking about it. When you call `sendResponseHeaders(200, 0)` a similar thing happens to what I'm asking for 101. The streams are not closed, and the handler is free to read the inputstream and write to the outputstream as it pleases. server.createContext( "/test", exchange -> { exchange.sendResponseHeaders(200, 0); exchange.getResponseBody().write("My Response".getBytes()); try (var is = exchange.getRequestBody()) { is.transferTo(exchange.getResponseBody()); } }); ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3401986420 From dfuchs at openjdk.org Tue Oct 14 13:54:05 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 13:54:05 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v7] In-Reply-To: References: Message-ID: <6ONK--z9SiJYKtnOqnj9L4WOchUZ4QDcpfmuLOWXKjo=.4b48b6dc-f09f-4027-800d-436d1c5e244a@github.com> On Tue, 14 Oct 2025 10:37:36 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's review, use a class level field for URLConnection test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 76: > 74: void afterEach() throws Exception { > 75: this.conn = null; > 76: Files.deleteIfExists(this.testFile); Suggestion: // the file should already have been deleted by the test method this.conn = null; Files.deleteIfExists(this.testFile); test/jdk/sun/net/www/protocol/file/FileURLConnStreamLeakTest.java line 97: > 95: // verify that the URLConnection isn't holding on to any file descriptors > 96: // of this test file. > 97: Files.delete(this.testFile); // must not fail Should we assert that Files.exists(this.testFile) is false? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2429273075 PR Review Comment: https://git.openjdk.org/jdk/pull/27633#discussion_r2429283854 From jpai at openjdk.org Tue Oct 14 13:54:26 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 13:54:26 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v4] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? > > As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Daniel's review - use POST instead of GET ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27793/files - new: https://git.openjdk.org/jdk/pull/27793/files/80da00de..247fe0b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27793&range=02-03 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27793.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27793/head:pull/27793 PR: https://git.openjdk.org/jdk/pull/27793 From jpai at openjdk.org Tue Oct 14 13:54:28 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 14 Oct 2025 13:54:28 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v3] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 13:33:37 GMT, Daniel Fuchs wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> forgot to include @bug id in the test definition > > test/jdk/java/net/httpclient/http3/H3RequestRejectedTest.java line 150: > >> 148: .setOption(H3_DISCOVERY, HTTP_3_URI_ONLY) >> 149: .uri(new URI(reqURI.toString() + "?iteration=" + i)) >> 150: .build(); > > To make sure the request is retried for the right reasons you might want to switch to POST rather than GET here, as GET may be retried whatever the reset reason. That's a good point. I've updated the PR accordingly. The test continues to fail in the absence of the fix that's made in this PR and passes with it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27793#discussion_r2429278554 From dfuchs at openjdk.org Tue Oct 14 14:20:34 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 14:20:34 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v4] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 13:54:26 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's review - use POST instead of GET Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27793#pullrequestreview-3335953859 From dfuchs at openjdk.org Tue Oct 14 14:33:09 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 14:33:09 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 07:21:21 GMT, Volkan Yazici wrote: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1145: > 1143: || exception instanceof ExecutionException > 1144: ? exception.getCause() > 1145: : exception; Suggestion: var unwrappedException = Utils.getCompletionCause(exception); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2429418936 From dfuchs at openjdk.org Tue Oct 14 14:33:11 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 14:33:11 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync In-Reply-To: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> References: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> Message-ID: On Tue, 14 Oct 2025 07:31:45 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1147: > >> 1145: var translatedException = unwrappedException instanceof Error >> 1146: ? unwrappedException >> 1147: : Utils.toIOException(exception); > > `toIOException()`, which is _only_ used in `Http3PushManager::cancelPendingPushPromise`, performs unwrapping of `CompletionException` and `ExecutionException` too, though it doesn't exclude `Error`. I considered following approaches: > > 1. Don't use `toIOException` and hard-code all the translation logic to here > 2. Update `toIOException()` to not wrap `Error` ? This implies I need to change method's return type from `IOException` to `Throwable`, and this creates problems at the `cancelPendingPushPromise()` call site, since it uses `Http3PushPromiseStream#cancel(IOException)` (note the required `IOException` argument!), which overrides `ExchangeImpl#cancel(IOException)`. In short, this is a dead end. > 3. Specialize on `Error` here, but still use `toIOException()` for the rest. > > I've implemented the 3rd option. But as time passes, I'm getting inclined towards hard-coding all the translation logic (1st option) *and* move `Utils::toIOException` to `Http3PushManager` as a `private` method. I'd appreciate your thoughts on the matter. Keep it in Utils. `ExchangeImpl#cancel(IOException)` is protocol agnostic which lets me think that maybe there are other places that do wrapping - or may need to do wrapping in the future. 3rd option LGTM ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2429420173 From djelinski at openjdk.org Tue Oct 14 15:02:56 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 15:02:56 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 07:31:40 GMT, Volkan Yazici wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test explicitly setting content length to zero > > test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 217: > >> 215: assertEquals(resp.statusCode(), 200, resp.body()); >> 216: assertEquals(resp.version(), version); >> 217: assertEquals(resp.body(), "Request completed"); > > If possible, you may consider verifying the response body in other test methods too, since, in particular, `OptionalContentLengthHandler` responds with 200 in two different scenarios. That's not possible in most cases: in HTTP/2 and HTTP/3 we don't send the content-length:0 header, we only send content-length when it's known up front and non-zero. In cases where it is possible it's usually not necessary - most of the time we don't really care if the content length was sent or not, as long as the server is able to figure it out. I'll add a check for the HTTP/1 + PUT/POST case, since that's special-cased by this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2429520632 From duke at openjdk.org Tue Oct 14 15:21:16 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 15:21:16 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: <0Og7PHWsxpCRIwXRFzpyad8_auSyAxOTowBxMJsYlU4=.340610a0-6287-4a2f-97e8-5dc1f728bd99@github.com> Message-ID: On Tue, 14 Oct 2025 15:05:04 GMT, Daniel Fuchs wrote: > But your PR changes the request body input stream preemptively, That is true, but it's only for GET requests. Thus it effectively remains optional as regular GET request handlers wouldn't attempt to read the body. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3402387339 From dfuchs at openjdk.org Tue Oct 14 15:08:05 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 15:08:05 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: <0Og7PHWsxpCRIwXRFzpyad8_auSyAxOTowBxMJsYlU4=.340610a0-6287-4a2f-97e8-5dc1f728bd99@github.com> References: <0Og7PHWsxpCRIwXRFzpyad8_auSyAxOTowBxMJsYlU4=.340610a0-6287-4a2f-97e8-5dc1f728bd99@github.com> Message-ID: On Tue, 14 Oct 2025 13:33:45 GMT, Josiah Noel wrote: > Requiring a manual call of sendResponseHeaders(101, 0) and the requirement to custom implement the entire protocol appears pretty opt in to me. Right. But your PR changes the request body input stream preemptively, before `sendResponseHeaders(101, 0)` is called. Which let me think that `sendResponseHeaders` is not the right API for doing this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3402323003 From djelinski at openjdk.org Tue Oct 14 15:11:53 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 15:11:53 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v3] In-Reply-To: References: Message-ID: > Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. > > This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. > > The existing ContentLengthHeaderTest was extended to cover the modified scenarios. > > Tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Check that content-length is sent on POST/PUT with empty body ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27727/files - new: https://git.openjdk.org/jdk/pull/27727/files/fc6a7edb..da849bf5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=01-02 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27727/head:pull/27727 PR: https://git.openjdk.org/jdk/pull/27727 From dfuchs at openjdk.org Tue Oct 14 15:43:47 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 15:43:47 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: Message-ID: <1foqAHhVHWZn2p6zDrkjAdQQSd0PL_ZD5D00qovf7io=.b57b0fe7-d821-4ee9-a668-1366d933ab5d@github.com> On Tue, 14 Oct 2025 15:00:38 GMT, Daniel Jeli?ski wrote: >> test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 217: >> >>> 215: assertEquals(resp.statusCode(), 200, resp.body()); >>> 216: assertEquals(resp.version(), version); >>> 217: assertEquals(resp.body(), "Request completed"); >> >> If possible, you may consider verifying the response body in other test methods too, since, in particular, `OptionalContentLengthHandler` responds with 200 in two different scenarios. > > That's not possible in most cases: in HTTP/2 and HTTP/3 we don't send the content-length:0 header, we only send content-length when it's known up front and non-zero. > In cases where it is possible it's usually not necessary - most of the time we don't really care if the content length was sent or not, as long as the server is able to figure it out. > > I'll add a check for the HTTP/1 + PUT/POST case, since that's special-cased by this PR. If I'm not mistaken in case of H2/H3 you could verify that: assertTrue(List.of("Request completed, no content length", "Request completed").contains(resp.body()), "Unexpected response: " + resp.body()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2429642984 From dfuchs at openjdk.org Tue Oct 14 15:48:08 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 15:48:08 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 21:22:49 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update UpgradeInputStream.java So your proposal is that we support switching protocols only for GET requests, and only for those that have no Content-length header in the request header? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3402493526 From duke at openjdk.org Tue Oct 14 15:51:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 15:51:02 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 21:22:49 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update UpgradeInputStream.java Essentially yes, because that's all that's needed to support implementing the websocket protocol. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3402505729 From dfuchs at openjdk.org Tue Oct 14 16:28:43 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 16:28:43 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 21:22:49 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update UpgradeInputStream.java But that would be an incompatible change, isn't it? Consider the following: httpserver.createContext("/echo/", (exch) -> { byte[] bytes; try (var is = exch.getRequestBody()) { bytes = is.readAllBytes(); } exch.sendResponseHeaders(200, bytes.length == 0 ? -1 : bytes.length); try (var os = exch.getResponseBody()) { if (bytes.length > 0) os.write(bytes); } }); wouldn't that now block forever if the request contains an upgrade header? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3402699078 From duke at openjdk.org Tue Oct 14 16:46:27 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 16:46:27 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v3] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 16:24:01 GMT, Daniel Fuchs wrote: > But that would be an incompatible change, isn't it? That we even return an inputstream for a GET request is pretty strange but yeah that would indeed block forever. I'll make it so that it'll return the upgrade stream only after 101 is sent to keep compatibility. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3402772924 From duke at openjdk.org Tue Oct 14 17:22:56 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 17:22:56 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v4] In-Reply-To: References: Message-ID: <0DAPDRkCvD4a5fVq0EeGROyf8H2YXIc4IOL9r17KSTM=.35c45250-a77b-48bb-9981-389dba76d1cc@github.com> > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: fix compatibility ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/ee8b2bcd..49772413 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=02-03 Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Tue Oct 14 17:34:09 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 14 Oct 2025 17:34:09 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: tab ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/49772413..7818864f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From djelinski at openjdk.org Tue Oct 14 18:00:20 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 18:00:20 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v4] In-Reply-To: References: Message-ID: > Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. > > This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. > > The existing ContentLengthHeaderTest was extended to cover the modified scenarios. > > Tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: More strict verification of content-length handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27727/files - new: https://git.openjdk.org/jdk/pull/27727/files/da849bf5..76dc259d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=02-03 Stats: 40 lines in 1 file changed: 7 ins; 29 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27727/head:pull/27727 PR: https://git.openjdk.org/jdk/pull/27727 From djelinski at openjdk.org Tue Oct 14 18:00:21 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 18:00:21 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: <1foqAHhVHWZn2p6zDrkjAdQQSd0PL_ZD5D00qovf7io=.b57b0fe7-d821-4ee9-a668-1366d933ab5d@github.com> References: <1foqAHhVHWZn2p6zDrkjAdQQSd0PL_ZD5D00qovf7io=.b57b0fe7-d821-4ee9-a668-1366d933ab5d@github.com> Message-ID: On Tue, 14 Oct 2025 15:41:12 GMT, Daniel Fuchs wrote: >> That's not possible in most cases: in HTTP/2 and HTTP/3 we don't send the content-length:0 header, we only send content-length when it's known up front and non-zero. >> In cases where it is possible it's usually not necessary - most of the time we don't really care if the content length was sent or not, as long as the server is able to figure it out. >> >> I'll add a check for the HTTP/1 + PUT/POST case, since that's special-cased by this PR. > > If I'm not mistaken in case of H2/H3 you could verify that: > > > assertTrue(List.of("Request completed, no content length", "Request completed").contains(resp.body()), "Unexpected response: " + resp.body()); I ended up removing the `OptionalContentLengthHandler`. It didn't feel right anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2430005728 From dfuchs at openjdk.org Tue Oct 14 18:15:30 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 14 Oct 2025 18:15:30 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v4] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 18:00:20 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > More strict verification of content-length handling test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 224: > 222: assertEquals(resp.statusCode(), 200, resp.body()); > 223: assertEquals(resp.version(), version); > 224: assertEquals(resp.body(), "Request completed"); Ok - so now: remove or add everywhere? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2430042438 From djelinski at openjdk.org Tue Oct 14 18:37:35 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 18:37:35 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v5] In-Reply-To: References: Message-ID: > Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. > > This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. > > The existing ContentLengthHeaderTest was extended to cover the modified scenarios. > > Tier1-3 tests continue to pass. Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: Remove leftover check ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27727/files - new: https://git.openjdk.org/jdk/pull/27727/files/76dc259d..a2d13e45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27727&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27727.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27727/head:pull/27727 PR: https://git.openjdk.org/jdk/pull/27727 From djelinski at openjdk.org Tue Oct 14 18:41:02 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 14 Oct 2025 18:41:02 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v4] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 18:12:21 GMT, Daniel Fuchs wrote: >> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: >> >> More strict verification of content-length handling > > test/jdk/java/net/httpclient/ContentLengthHeaderTest.java line 224: > >> 222: assertEquals(resp.statusCode(), 200, resp.body()); >> 223: assertEquals(resp.version(), version); >> 224: assertEquals(resp.body(), "Request completed"); > > Ok - so now: remove or add everywhere? Removed. It no longer served any purpose. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2430101169 From josiahnoel at gmail.com Tue Oct 14 20:54:56 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Tue, 14 Oct 2025 16:54:56 -0400 Subject: HttpServer Create Convenience Method Message-ID: Long time no see, As you know, to create a server you need to do something like: HttpServer. create(new InetSocketAddress(8080), 0); Perchance would we be amenable to adding a convenience method to make it as easy as HttpServer.create(8080) -- Cheers, Josiah. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Tue Oct 14 20:58:02 2025 From: ethan at mccue.dev (Ethan McCue) Date: Tue, 14 Oct 2025 16:58:02 -0400 Subject: HttpServer Create Convenience Method In-Reply-To: References: Message-ID: I think the 0 at the end is worth tackling, it's not too much of a burden to pass the InetSocketAddress On Tue, Oct 14, 2025 at 4:56?PM Josiah Noel wrote: > Long time no see, > > As you know, to create a server you need to do something like: HttpServer. > create(new InetSocketAddress(8080), 0); > > Perchance would we be amenable to adding a convenience method to make it > as easy as HttpServer.create(8080) > > -- > Cheers, Josiah. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Wed Oct 15 02:03:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 15 Oct 2025 02:03:23 GMT Subject: RFR: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly [v4] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 13:54:26 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Daniel's review - use POST instead of GET Thank you both for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27793#issuecomment-3404240324 From jpai at openjdk.org Wed Oct 15 02:03:24 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 15 Oct 2025 02:03:24 GMT Subject: Integrated: 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 09:35:51 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix the implementation in HttpClient to correctly handle the H3_REQUEST_REJECTED error code? > > As noted in https://bugs.openjdk.org/browse/JDK-8369812, the current implementation in the HttpClient treats this like an error and causes the HTTP request to fail. The proposed change in this PR addresses this by marking a request which was reset due to H3_REQUEST_REJECTED as unprocessed. This then allows the `MultiExchange` to reissue the request afresh. This new behaviour matches the expectation specified for this error code in the HTTP/3 RFC. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. This pull request has now been integrated. Changeset: 42b2999c Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/42b2999c31d63d0f8326c83e95eff83f5a467926 Stats: 223 lines in 2 files changed: 216 ins; 2 del; 5 mod 8369812: HttpClient doesn't handle H3_REQUEST_REJECTED correctly Reviewed-by: dfuchs, djelinski ------------- PR: https://git.openjdk.org/jdk/pull/27793 From vyazici at openjdk.org Wed Oct 15 08:16:13 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 08:16:13 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v5] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 18:37:35 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Remove leftover check Marked as reviewed by vyazici (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27727#pullrequestreview-3338987327 From vyazici at openjdk.org Wed Oct 15 08:16:14 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 08:16:14 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v2] In-Reply-To: References: <1foqAHhVHWZn2p6zDrkjAdQQSd0PL_ZD5D00qovf7io=.b57b0fe7-d821-4ee9-a668-1366d933ab5d@github.com> Message-ID: On Tue, 14 Oct 2025 17:55:23 GMT, Daniel Jeli?ski wrote: >> If I'm not mistaken in case of H2/H3 you could verify that: >> >> >> assertTrue(List.of("Request completed, no content length", "Request completed").contains(resp.body()), "Unexpected response: " + resp.body()); > > I ended up removing the `OptionalContentLengthHandler`. It didn't feel right anyway. `OptionalContentLengthHandler` gone feels better. This also implies that the check is stricter: we either expect the `Content-Length`, or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27727#discussion_r2431557038 From vyazici at openjdk.org Wed Oct 15 08:41:52 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 08:41:52 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v2] In-Reply-To: References: Message-ID: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Use `Utils::getCompletionCause` Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27787/files - new: https://git.openjdk.org/jdk/pull/27787/files/8fba3e5a..16440461 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From dfuchs at openjdk.org Wed Oct 15 10:04:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 10:04:06 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v5] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 18:37:35 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Remove leftover check Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27727#pullrequestreview-3339499280 From dfuchs at openjdk.org Wed Oct 15 10:10:23 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 10:10:23 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v5] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 18:37:35 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Remove leftover check @djelinski you should probably Finalize the CSR [JDK-8369533](https://bugs.openjdk.org/browse/JDK-8369533) now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27727#issuecomment-3405616198 From dfuchs at openjdk.org Wed Oct 15 10:12:27 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 10:12:27 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 17:34:09 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > tab Before going any further in the review I would like to see how this new feature would be documented. If we eventually decide to take it on board, then more extensive tests will be needed too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3405626434 From vyazici at openjdk.org Wed Oct 15 12:00:25 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 12:00:25 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 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 five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap - Use `Utils::getCompletionCause` Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> - Document exception wrapping in `HttpClientImpl::send` - Fix test failures - Ensure `sendAsync` wraps execution failures in `IOException` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27787/files - new: https://git.openjdk.org/jdk/pull/27787/files/16440461..e357bbd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=01-02 Stats: 5515 lines in 178 files changed: 1981 ins; 3246 del; 288 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From vyazici at openjdk.org Wed Oct 15 12:00:27 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 12:00:27 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 08:41:52 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Use `Utils::getCompletionCause` > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> `tier1-2` passes on several platforms using e357bbd7149. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27787#issuecomment-3406040217 From duke at openjdk.org Wed Oct 15 13:13:22 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 13:13:22 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 10:10:00 GMT, Daniel Fuchs wrote: > I would like to see how this new feature would be documented My thought was to add an implnote to `getRequestBody` saying something to the effect of: `@implNote For GET requests with an Upgrade header, the returned stream will not return any data unless the protocol switch is first performed by calling {@link #sendResponseHeaders(int, long) sendResponseHeaders(101, 0)}` For sendResponseHeaders, it's currently already implied that you can send 101. So I would add an implnote clarifying the behavior. Something like: ` @implNote This implementation offers limited support for connection upgrade on GET requests. If the request included an {@code Upgrade} header, and the response code is 101 (Switching Protocols), then the handler can use the streams returned by {@link #getRequestBody()} and {@link #getResponseBody()} to implement the desired protocol. ` > more extensive tests will be needed too. Naturally, tell me what other cases you'd like and it shall be done ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3406382792 From dfuchs at openjdk.org Wed Oct 15 13:49:24 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 13:49:24 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> References: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> Message-ID: On Tue, 14 Oct 2025 09:05:54 GMT, Volkan Yazici 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap >> - Use `Utils::getCompletionCause` >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> >> - Document exception wrapping in `HttpClientImpl::send` >> - Fix test failures >> - Ensure `sendAsync` wraps execution failures in `IOException` > > test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java line 476: > >> 474: } >> 475: >> 476: private static boolean throwableCausalChainContainsInstanceOf( > > `HttpClientImpl::send` wraps `IOException` (wrapping `IllegalArgumentException`) thrown by `sendAsync` in an `IOException` again. As a result, the existing checks performing _"unwrapping of `IOException` once"_ do not work anymore. Since the existing unwrapping was not strict ? that is, they're not enforced, but optionally unwrapping if types match in the causal chain ? I've further relaxed it with scanning the causal chain. I wonder if we should add the wrapping only when sendAsync is not called by send? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2432636766 From dfuchs at openjdk.org Wed Oct 15 13:52:42 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 13:52:42 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> References: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> Message-ID: On Tue, 14 Oct 2025 09:11:19 GMT, Volkan Yazici 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap >> - Use `Utils::getCompletionCause` >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> >> - Document exception wrapping in `HttpClientImpl::send` >> - Fix test failures >> - Ensure `sendAsync` wraps execution failures in `IOException` > > test/jdk/java/net/httpclient/http3/StopSendingTest.java line 184: > >> 182: } >> 183: >> 184: private static boolean throwableCausalChainContainsInstanceOf( > > `HttpClientImpl::send` wraps `IOException` (wrapping `CancellationException`) thrown by `sendAsync` in an `IOException` again. As a result, the existing checks performing _"unwrapping of `IOException` once"_ do not work anymore. Since the existing unwrapping was not strict ? that is, they're not enforced, but optionally unwrapping if types match in the causal chain ? I've further relaxed it with scanning the causal chain. We don't want to wrap CancellationException. That's a valid exception for any CompletableFuture to throw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2432648591 From dfuchs at openjdk.org Wed Oct 15 13:55:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 13:55:45 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 12:00:25 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap > - Use `Utils::getCompletionCause` > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > - Document exception wrapping in `HttpClientImpl::send` > - Fix test failures > - Ensure `sendAsync` wraps execution failures in `IOException` src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1112: > 1110: res = translateSendAsyncExecFailure(res); > 1111: > 1112: if (exchangeExecutor != null) { Suggestion: if (exchangeExecutor != null) { // we're called by sendAsync() - make sure we translate exceptions res = translateSendAsyncExecFailure(res); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2432657482 From dfuchs at openjdk.org Wed Oct 15 13:59:30 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 13:59:30 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 12:00:25 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap > - Use `Utils::getCompletionCause` > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > - Document exception wrapping in `HttpClientImpl::send` > - Fix test failures > - Ensure `sendAsync` wraps execution failures in `IOException` src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1145: > 1143: // Except `Error`s, wrap failures inside an `IOException`. > 1144: // This is required to comply with the specification of `HttpClient::sendAsync`. > 1145: var translatedException = unwrappedException instanceof Error Suggestion: var translatedException = unwrappedException instanceof Error || unwrappedException instanceof CancelledException ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2432674310 From dfuchs at openjdk.org Wed Oct 15 14:06:20 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 14:06:20 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 12:00:25 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap > - Use `Utils::getCompletionCause` > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > - Document exception wrapping in `HttpClientImpl::send` > - Fix test failures > - Ensure `sendAsync` wraps execution failures in `IOException` test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java line 683: > 681: public boolean test(Throwable throwable) { > 682: // `UncheckedIOException` is peeled off by `HttpClientImpl::translateSendAsyncExecFailure` > 683: return throwable instanceof CustomIOException; We want to preserve the UncheckedIOException here. We don't want to peel it off. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2432699343 From michaelm at openjdk.org Wed Oct 15 14:20:17 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 15 Oct 2025 14:20:17 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 17:34:09 GMT, Josiah Noel wrote: >> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request >> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed >> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream >> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > tab Here is a proposal for discussion. This would be added to the end of the class level docs for HttpExchange ` Upgrading HTTP/1.1 connections
Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching the underlying connection from the HTTP stack. The {@link InputStream} and {@link OutputStream} returned from {@link #getRequestBody()} and {@link #getResponseBody()} respectively, after sending the 101 response, returns raw streams to the underlying socket. {@code sendResponseHeaders(101, -1)} must be called prior to obtaining the detached input and output streams. It is also an error to send a 101 response if no {@code Upgrade} header was present in the request, or the request was anything other than a GET (or CONNECT?) or to pass a content length other than {@code -1}. Other than that, the library does not restrict or interpret the Upgrade header value. It is up to the calling code to implement whatever higher level protocol is required over the underlying socket. It is up to the calling code to eventually obtain and eventually close both the detached {@link #getRe questBody() InputStream} and {@link #getResponseBody() OutputStream} to prevent resource leaks. Closing the exchange after {@code sendResponseHeaders(101, -1)} has been called has no effect on these streams. Terminating the server with {@link HttpServer.stop(int)} closes all sockets associated with the server including any sockets detached through this mechanism.` The apidoc for HttpServer.stop would need to mention that sockets detached from the upgrade mechanism are also closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3406670813 From dfuchs at openjdk.org Wed Oct 15 15:28:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 15:28:45 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 14:17:20 GMT, Michael McMahon wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> tab > > Here is a proposal for discussion. This would be added to the end of the class level docs for HttpExchange > > > Upgrading HTTP/1.1 connections > >
Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching > the underlying connection from the HTTP stack. The {@link InputStream} and {@link OutputStream} returned from > {@link #getRequestBody()} and {@link #getResponseBody()} respectively, after sending the 101 response, returns raw > streams to the underlying socket. {@code sendResponseHeaders(101, -1)} must be called prior to obtaining the > detached input and output streams. It is also an error to send a 101 response if no {@code Upgrade} header was present > in the request, or the request was anything other than a GET (or CONNECT?) or to pass a content length other than > {@code -1}. Other than that, the library does not restrict or interpret the Upgrade header value. It is up to the calling > code to implement whatever higher level protocol is required over the underlying socket. It is up to the calling code to > eventually obtain and eventually close both the detached {@link #getRequestBody() InputStream} and > {@link#getResponseBody() OutputStream} to prevent resource leaks. Closing the exchange after {@code > sendResponseHeaders(101, -1)} has been called has no effect on these streams. Terminating the server with {@link > HttpServer.stop(int)} closes all sockets associated with the server including any sockets detached through this > mechanism. > > > The apidoc for HttpServer.stop would need to mention that sockets detached from the upgrade mechanism are also closed. Thanks @Michael-Mc-Mahon for driving this discussion. Would this text be normative - that it - would any implementation plugged through the SPI need to support this? If not we should find some way to tie that to the JDK built-in implementation. I know that the HttpServer API itself is not part of the Java SE spec - but maybe we should set some expectations of what an implementation plugged through the SPI must, should, or might do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407011129 From duke at openjdk.org Wed Oct 15 15:36:05 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 15:36:05 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 14:17:20 GMT, Michael McMahon wrote: > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching the underlying connection from the HTTP stack. Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams. > Closing the exchange after {@code sendResponseHeaders(101, -1)} has been called has no effect on these streams. Doesn't closing the exchange call close on both the input/output stream? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407059247 From dfuchs at openjdk.org Wed Oct 15 15:46:11 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 15 Oct 2025 15:46:11 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 15:33:18 GMT, Josiah Noel wrote: > > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching > > the underlying connection from the HTTP stack. > > Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams. Well - no. The connection will be reused for the next request when the chunked streams are closed. > > Closing the exchange after {@code > > sendResponseHeaders(101, -1)} has been called has no effect on these streams. > > Doesn't closing the exchange call close on both the input/output stream? We may need to link back to the upgrade paragraph in `HttpExchange::close`. Good remark. The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407102453 From duke at openjdk.org Wed Oct 15 15:53:24 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 15:53:24 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: <-pewdnhYp_03CwXeGbq8HTF99oBfoqi8YDd62Je8uvc=.ceb75c82-ae51-4894-97d8-b14250db2a3c@github.com> On Wed, 15 Oct 2025 15:42:44 GMT, Daniel Fuchs wrote: > Well - no. The connection will be reused for the next request when the chunked streams are closed. I see, we should probably close the actual streams when calling close on the upgrade stream. > The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective. I suppose you're right, but it would be nice if calling close on HttpExchange would also close the upgraded streams. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407141947 From duke at openjdk.org Wed Oct 15 16:12:51 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 16:12:51 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v6] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with two additional commits since the last revision: - Create UpgradeOutputStream.java - close raw streams ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/7818864f..a648a7ba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=04-05 Stats: 90 lines in 2 files changed: 81 ins; 2 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From michaelm at openjdk.org Wed Oct 15 16:12:52 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 15 Oct 2025 16:12:52 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: Message-ID: <6qB_v_fKlxQNfsgeDK1EiVyN4cs3fsUilVtnt8P9CnE=.67817748-52b3-4b9b-b835-4ff8ecff673a@github.com> On Wed, 15 Oct 2025 15:42:44 GMT, Daniel Fuchs wrote: > > > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching > > > the underlying connection from the HTTP stack. > > > > > > Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams. > > Well - no. The connection will be reused for the next request when the chunked streams are closed. > Chunked encoding does not expose the "raw" socket either. There is a framing structure (though primitive) associated with each chunk. > > > Closing the exchange after {@code > > > sendResponseHeaders(101, -1)} has been called has no effect on these streams. > > > > > > Doesn't closing the exchange call close on both the input/output stream? > > We may need to link back to the upgrade paragraph in `HttpExchange::close`. Good remark. The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407248358 From michaelm at openjdk.org Wed Oct 15 16:15:34 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 15 Oct 2025 16:15:34 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: <6qB_v_fKlxQNfsgeDK1EiVyN4cs3fsUilVtnt8P9CnE=.67817748-52b3-4b9b-b835-4ff8ecff673a@github.com> References: <6qB_v_fKlxQNfsgeDK1EiVyN4cs3fsUilVtnt8P9CnE=.67817748-52b3-4b9b-b835-4ff8ecff673a@github.com> Message-ID: On Wed, 15 Oct 2025 16:10:02 GMT, Michael McMahon wrote: >>> > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching >>> > the underlying connection from the HTTP stack. >>> >>> Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams. >> >> Well - no. The connection will be reused for the next request when the chunked streams are closed. >> >> >>> > Closing the exchange after {@code >>> > sendResponseHeaders(101, -1)} has been called has no effect on these streams. >>> >>> Doesn't closing the exchange call close on both the input/output stream? >> >> We may need to link back to the upgrade paragraph in `HttpExchange::close`. Good remark. >> The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective. > >> > > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching >> > > the underlying connection from the HTTP stack. >> > >> > >> > Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams. >> >> Well - no. The connection will be reused for the next request when the chunked streams are closed. >> > > Chunked encoding does not expose the "raw" socket either. There is a framing structure (though primitive) > associated with each chunk. > >> > > Closing the exchange after {@code >> > > sendResponseHeaders(101, -1)} has been called has no effect on these streams. >> > >> > >> > Doesn't closing the exchange call close on both the input/output stream? >> >> We may need to link back to the upgrade paragraph in `HttpExchange::close`. Good remark. The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective. > Thanks @Michael-Mc-Mahon for driving this discussion. Would this text be normative - that it - would any implementation plugged through the SPI need to support this? If not we should find some way to tie that to the JDK built-in implementation. I know that the HttpServer API itself is not part of the Java SE spec - but maybe we should set some expectations of what an implementation plugged through the SPI must, should, or might do. Maybe we could allow sendResponseHeaders to throw `UnsupportedOperationException` if the function is not supported. That would be a fully compatible change I think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407263610 From duke at openjdk.org Wed Oct 15 16:49:14 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 16:49:14 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v7] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: add exception test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/a648a7ba..cc80cd9c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=05-06 Stats: 42 lines in 1 file changed: 40 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Wed Oct 15 17:10:11 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 17:10:11 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5] In-Reply-To: References: <6qB_v_fKlxQNfsgeDK1EiVyN4cs3fsUilVtnt8P9CnE=.67817748-52b3-4b9b-b835-4ff8ecff673a@github.com> Message-ID: On Wed, 15 Oct 2025 16:13:15 GMT, Michael McMahon wrote: > Would this text be normative - that it - would any implementation plugged through the SPI need to support this? While some implementations do it that way I'm not completely sure it's right to make all of them try to implement Upgrade. > Maybe we could allow sendResponseHeaders to throw UnsupportedOperationException if the function is not supported. Not totally sold on this > Actually that won't work. Let me think about it ... It really needs to be a new method to allow for existing implementations that don't support it ... Something like sendUpgradeResponse() with a default implementation that throws UOE. A separate method to do essentially the same thing as sendResponseHeaders? The main change is the implicit swap of the streams. I would be agreeable with this if `sendUpgradeResponse()` simply called `sendResponseHeaders(101, 0)` for convenience. For context on why I would prefer to stick with `sendResponseHeaders`, there are other impls that currently support sending 101 in this way and I would like my code to be compatible so I can cleanly switch to the JDK implementation (Assuming the feature is accepted). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407455711 From duke at openjdk.org Wed Oct 15 17:46:56 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 17:46:56 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v10] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update module-info.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/1164702a..061e504b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Wed Oct 15 17:47:44 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 17:47:44 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v8] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update SwitchingProtocolTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/cc80cd9c..b8f58985 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From vyazici at openjdk.org Wed Oct 15 19:34:10 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 19:34:10 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v4] In-Reply-To: References: Message-ID: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Discard `CancellationException` and only translate from exceptions from `sendAsync()` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27787/files - new: https://git.openjdk.org/jdk/pull/27787/files/e357bbd7..ec28a849 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=02-03 Stats: 103 lines in 6 files changed: 53 ins; 36 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From vyazici at openjdk.org Wed Oct 15 19:40:34 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 19:40:34 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 13:52:39 GMT, Daniel Fuchs 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into sendAsyncExWrap >> - Use `Utils::getCompletionCause` >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> >> - Document exception wrapping in `HttpClientImpl::send` >> - Fix test failures >> - Ensure `sendAsync` wraps execution failures in `IOException` > > src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1112: > >> 1110: res = translateSendAsyncExecFailure(res); >> 1111: >> 1112: if (exchangeExecutor != null) { > > Suggestion: > > if (exchangeExecutor != null) { > // we're called by sendAsync() - make sure we translate exceptions > res = translateSendAsyncExecFailure(res); Implemented in ec28a849112. This rendered the need to touch following tests unnecessary: - `AbstractThrowingPublishers` - `InvalidInputStreamSubscriptionRequest` - `http3/H3QuicTLSConnection` - `http3/StopSendingTest` Hence, reverted these changes. > src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 1145: > >> 1143: // Except `Error`s, wrap failures inside an `IOException`. >> 1144: // This is required to comply with the specification of `HttpClient::sendAsync`. >> 1145: var translatedException = unwrappedException instanceof Error > > Suggestion: > > var translatedException = unwrappedException instanceof Error > || unwrappedException instanceof CancelledException Implemented in ec28a849112. > test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java line 683: > >> 681: public boolean test(Throwable throwable) { >> 682: // `UncheckedIOException` is peeled off by `HttpClientImpl::translateSendAsyncExecFailure` >> 683: return throwable instanceof CustomIOException; > > We want to preserve the UncheckedIOException here. We don't want to peel it off. I'm not able to follow. `UncheckedIOE` is peeled off by `Utils::toIOException` in `translateSendAsyncExecFailure()`. Mind elaborating on what are you suggesting? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2433723097 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2433723572 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2433729561 From vyazici at openjdk.org Wed Oct 15 19:40:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 15 Oct 2025 19:40:37 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v4] In-Reply-To: References: <5kl9ktX5CQp7QmNR4gJNUILLe4AupgDIAeDAq5QjR84=.ece0235d-78fd-4114-bf9b-e83fa3f2ef8a@github.com> Message-ID: On Wed, 15 Oct 2025 13:46:51 GMT, Daniel Fuchs wrote: >> test/jdk/java/net/httpclient/InvalidInputStreamSubscriptionRequest.java line 476: >> >>> 474: } >>> 475: >>> 476: private static boolean throwableCausalChainContainsInstanceOf( >> >> `HttpClientImpl::send` wraps `IOException` (wrapping `IllegalArgumentException`) thrown by `sendAsync` in an `IOException` again. As a result, the existing checks performing _"unwrapping of `IOException` once"_ do not work anymore. Since the existing unwrapping was not strict ? that is, they're not enforced, but optionally unwrapping if types match in the causal chain ? I've further relaxed it with scanning the causal chain. > > I wonder if we should add the wrapping only when sendAsync is not called by send? Implemented in ec28a849112, and reverted this test change. >> test/jdk/java/net/httpclient/http3/StopSendingTest.java line 184: >> >>> 182: } >>> 183: >>> 184: private static boolean throwableCausalChainContainsInstanceOf( >> >> `HttpClientImpl::send` wraps `IOException` (wrapping `CancellationException`) thrown by `sendAsync` in an `IOException` again. As a result, the existing checks performing _"unwrapping of `IOException` once"_ do not work anymore. Since the existing unwrapping was not strict ? that is, they're not enforced, but optionally unwrapping if types match in the causal chain ? I've further relaxed it with scanning the causal chain. > > We don't want to wrap CancellationException. That's a valid exception for any CompletableFuture to throw. Implemented in ec28a849112, and reverted this test change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2433724894 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2433725558 From duke at openjdk.org Wed Oct 15 19:57:43 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 19:57:43 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v9] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update SwitchingProtocolTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/b8f58985..3d1e7f58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=07-08 Stats: 41 lines in 1 file changed: 0 ins; 39 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Wed Oct 15 21:07:46 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 15 Oct 2025 21:07:46 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v10] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update SwitchingProtocolTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/3d1e7f58..fb551787 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=08-09 Stats: 41 lines in 1 file changed: 39 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Thu Oct 16 02:25:01 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 16 Oct 2025 02:25:01 GMT Subject: RFR: 8347167: Implementation in com.sun.net.httpserver.Headers.normalize() can be improved In-Reply-To: References: Message-ID: <2zEF_K5W6P5wIqU7_lqJb0sZ2ZsUj0W3dGNUVAezbJc=.2e935605-eea2-47ad-9e0b-708ff2f4e230@github.com> On Mon, 15 Sep 2025 02:50:27 GMT, Josiah Noel wrote: > Following the direction outlined in the net-dev discussion, I've updated the `com.sun.net.httpserver.Headers.normalize()` method to no longer allocate a superfluous char array when the header is already normalized. Let me know if anything else is required to move forward ------------- PR Comment: https://git.openjdk.org/jdk/pull/27276#issuecomment-3408924255 From vyazici at openjdk.org Thu Oct 16 05:37:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 16 Oct 2025 05:37:45 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v5] In-Reply-To: References: Message-ID: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Revert `AbstractThrowingPublishers` changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27787/files - new: https://git.openjdk.org/jdk/pull/27787/files/ec28a849..f2fa01df Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From djelinski at openjdk.org Thu Oct 16 11:08:22 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 16 Oct 2025 11:08:22 GMT Subject: RFR: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() [v5] In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 18:37:35 GMT, Daniel Jeli?ski wrote: >> Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. >> >> This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. >> >> The existing ContentLengthHeaderTest was extended to cover the modified scenarios. >> >> Tier1-3 tests continue to pass. > > Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision: > > Remove leftover check Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27727#issuecomment-3410333030 From djelinski at openjdk.org Thu Oct 16 11:08:24 2025 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 16 Oct 2025 11:08:24 GMT Subject: Integrated: 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 13:27:42 GMT, Daniel Jeli?ski wrote: > Do not send the Content-Length header on HTTP/1.1 requests when the content length is known to be zero and the method does not expect content or is unknown. > > This brings the HTTP/1.1 implementation in line with the recommendations from RFC 9110. > > The existing ContentLengthHeaderTest was extended to cover the modified scenarios. > > Tier1-3 tests continue to pass. This pull request has now been integrated. Changeset: ead35a75 Author: Daniel Jeli?ski URL: https://git.openjdk.org/jdk/commit/ead35a754bf3a545a1b68f28d3d939750f11af39 Stats: 160 lines in 2 files changed: 131 ins; 24 del; 5 mod 8358942: HttpClient adds Content-Length: 0 for a GET request with a BodyPublishers.noBody() Reviewed-by: dfuchs, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/27727 From dfuchs at openjdk.org Thu Oct 16 11:31:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 16 Oct 2025 11:31:03 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 19:37:33 GMT, Volkan Yazici wrote: >> test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java line 683: >> >>> 681: public boolean test(Throwable throwable) { >>> 682: // `UncheckedIOException` is peeled off by `HttpClientImpl::translateSendAsyncExecFailure` >>> 683: return throwable instanceof CustomIOException; >> >> We want to preserve the UncheckedIOException here. We don't want to peel it off. > > I'm not able to follow. `UncheckedIOE` is peeled off by `Utils::toIOException` in `translateSendAsyncExecFailure()`. Mind elaborating on what are you suggesting? Although it might look strange - we might want to wrap the UncheckedIOException instead of peeling it off. If the UncheckedIOException is generated by us (HttpClient implementation) then we most likely want to peel it off. But if it originates from custom code, peeling it off might hide important stack trace information. I am actually hesitating between the two possibilities. We see here that peeling of the UncheckedIOException from within sendAsync forces you to modify one test, where the UncheckedIOException was originating from custom code. I am not 100% sure we want do that. On the other hand - we don't want to add yet another version of toIOException. Let me think about this a bit more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2435550173 From dfuchs at openjdk.org Thu Oct 16 11:40:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 16 Oct 2025 11:40:06 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 11:27:41 GMT, Daniel Fuchs wrote: >> I'm not able to follow. `UncheckedIOE` is peeled off by `Utils::toIOException` in `translateSendAsyncExecFailure()`. Mind elaborating on what are you suggesting? > > Although it might look strange - we might want to wrap the UncheckedIOException instead of peeling it off. > If the UncheckedIOException is generated by us (HttpClient implementation) then we most likely want to peel it off. But if it originates from custom code, peeling it off might hide important stack trace information. > I am actually hesitating between the two possibilities. > > We see here that peeling of the UncheckedIOException from within sendAsync forces you to modify one test, where the UncheckedIOException was originating from custom code. I am not 100% sure we want do that. > > On the other hand - we don't want to add yet another version of toIOException. > > Let me think about this a bit more. OK - I think what you have is fine. Let's peel of UncheckedIOException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2435573867 From duke at openjdk.org Thu Oct 16 14:02:08 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 16 Oct 2025 14:02:08 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v11] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel 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 15 additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8368695 - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - add exception test - Create UpgradeOutputStream.java - close raw streams - tab - fix compatibility - Update UpgradeInputStream.java - ... and 5 more: https://git.openjdk.org/jdk/compare/33e49634...a3250508 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/fb551787..a3250508 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=09-10 Stats: 14699 lines in 301 files changed: 8907 ins; 5136 del; 656 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From dfuchs at openjdk.org Thu Oct 16 14:58:17 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 16 Oct 2025 14:58:17 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v10] In-Reply-To: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> References: <6vO3ve_6Iro8hf-8QMehOa-mULE7hUOqxEEOwPmi-08=.e9dd5688-95a1-4de0-bcfe-5bf778ade8cc@github.com> Message-ID: On Tue, 7 Oct 2025 09:25:20 GMT, Michael McMahon wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Update module-info.java > > Probably need a test for this as well OK - this looks good to me. @Michael-Mc-Mahon since the JBS issue is assigned to you will you act as a sponsor and create/drive the CSR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3411319240 From dfuchs at openjdk.org Thu Oct 16 15:08:24 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 16 Oct 2025 15:08:24 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v10] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 17:46:56 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update module-info.java Still a couple of issues to resolve - but we should be able to start with the CSR process now. src/jdk.httpserver/share/classes/module-info.java line 112: > 110: * be accessed by calling {@link HttpExchange#getHttpContext() getHttpContext()}{@link > 111: * HttpContext#getAttributes() .getAttributes()}.
> 112: * A new system property, {@systemProperty jdk.httpserver.attributes} (default value: {@code ""}) Suggestion: * A new system property, {@systemProperty jdk.httpserver.attributes} (default value: {@code ""}) `` without `` is making the doc build fail test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 74: > 72: var handler = new AttribHandler(); > 73: var server = HttpServer.create(new InetSocketAddress(LOOPBACK_ADDR,0), 10); > 74: server.createContext("/", handler).getAttributes().put("attr", "context-val"); So this tests the new behaviour by verifying that a context attribute is no longer visible from the exchange attributes. I believe we also need to test the opposite: an exchange attribute is not visible from the context. Also we want to verify that setting the new system property actually revert to the old behavior. ------------- Changes requested by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3345415766 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2436367685 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2436390889 From duke at openjdk.org Thu Oct 16 15:26:34 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 16 Oct 2025 15:26:34 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v11] In-Reply-To: References: Message-ID: <9BLwezQt3pGoT51RocZ3WzaKwSO10JsWpREDU8XsQ08=.e9174e06-5e15-4f34-9265-57ce935e1cf2@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: test context not affected ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/061e504b..4846a35d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=09-10 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Thu Oct 16 16:03:52 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 16 Oct 2025 16:03:52 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v12] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: test property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/4846a35d..b10aa5af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=10-11 Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Thu Oct 16 19:57:07 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 16 Oct 2025 19:57:07 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v12] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: reduce diff ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27751/files - new: https://git.openjdk.org/jdk/pull/27751/files/a3250508..8872bca5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=10-11 Stats: 12 lines in 1 file changed: 5 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Thu Oct 16 20:07:44 2025 From: duke at openjdk.org (Josiah Noel) Date: Thu, 16 Oct 2025 20:07:44 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v13] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Fix assertion statement in ExchangeAttributeTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/b10aa5af..c59d541d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From jpai at openjdk.org Fri Oct 17 12:28:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 17 Oct 2025 12:28:20 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v8] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Daniel's review - comment to test code - merge latest from master branch - Daniel's review, use a class level field for URLConnection - Volkan's review - add a comment in test - merge latest from master branch - Daniel's suggestion - add reachability fence - Volkan's review - merge latest from master branch - Daniel's suggestion - don't repeat/copy code from super() - merge latest from master branch - ... and 3 more: https://git.openjdk.org/jdk/compare/43f08329...05514212 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/f2938a1b..05514212 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=06-07 Stats: 18725 lines in 456 files changed: 10757 ins; 6594 del; 1374 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From dfuchs at openjdk.org Fri Oct 17 12:32:29 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 17 Oct 2025 12:32:29 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v8] In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 12:28:20 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Daniel's review - comment to test code > - merge latest from master branch > - Daniel's review, use a class level field for URLConnection > - Volkan's review - add a comment in test > - merge latest from master branch > - Daniel's suggestion - add reachability fence > - Volkan's review > - merge latest from master branch > - Daniel's suggestion - don't repeat/copy code from super() > - merge latest from master branch > - ... and 3 more: https://git.openjdk.org/jdk/compare/02fa8ac8...05514212 Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27633#pullrequestreview-3350060780 From vyazici at openjdk.org Fri Oct 17 18:43:46 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 17 Oct 2025 18:43:46 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize Message-ID: Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? ------------- Commit messages: - Clamp `Utils::BUFSIZE` Changes: https://git.openjdk.org/jdk/pull/27874/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367976 Stats: 230 lines in 4 files changed: 216 ins; 10 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From iklam at openjdk.org Fri Oct 17 22:27:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 17 Oct 2025 22:27:35 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets Message-ID: By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. ------------- Commit messages: - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets Changes: https://git.openjdk.org/jdk/pull/27880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368199 Stats: 38 lines in 7 files changed: 5 ins; 30 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From liach at openjdk.org Sat Oct 18 02:51:01 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Oct 2025 02:51:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69: > 67: public class SharedSecrets { > 68: // This field is not necessarily stable > 69: private static JavaAWTFontAccess javaAWTFontAccess; Does aot initialization work with this field? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441536894 From iklam at openjdk.org Sat Oct 18 04:06:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 18 Oct 2025 04:06:00 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Sat, 18 Oct 2025 02:48:42 GMT, Chen Liang wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 69: > >> 67: public class SharedSecrets { >> 68: // This field is not necessarily stable >> 69: private static JavaAWTFontAccess javaAWTFontAccess; > > Does aot initialization work with this field? I think this field is safe. There are two places that could set it, but they will always set it to an instance of `JavaAWTFontAccessImpl`, which is stateless. https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/NumericShaper.java#L148-L149 https://github.com/openjdk/jdk/blob/eff6439e75d79c67370e79638024296e01101b48/src/java.desktop/share/classes/java/awt/font/TextAttribute.java#L251-L252 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2441561760 From liach at openjdk.org Sat Oct 18 04:18:00 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 18 Oct 2025 04:18:00 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Archiving the accessors should be fine. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3352526259 From dfuchs at openjdk.org Mon Oct 20 09:40:07 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Oct 2025 09:40:07 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 18:36:39 GMT, Volkan Yazici wrote: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? You will also need to update module-info.java where the property is documented, to indicate what is the range of valid values and what happens if an invalid value is provided. https://github.com/openjdk/jdk/blob/8c775e299dbf651c3be1ba84b9e50356a3503861/src/java.net.http/share/classes/module-info.java#L49C1-L52C9 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27874#issuecomment-3421253265 From vyazici at openjdk.org Mon Oct 20 10:09:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 20 Oct 2025 10:09:37 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v2] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Update `module-info.java` docs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/67133467..148d4268 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From vyazici at openjdk.org Mon Oct 20 10:15:04 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 20 Oct 2025 10:15:04 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 09:37:31 GMT, Daniel Fuchs wrote: > You will also need to update module-info.java Implemented in 148d4268af1. I presume this warrants a CSR, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27874#issuecomment-3421406737 From msheppar at openjdk.org Mon Oct 20 11:13:14 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 20 Oct 2025 11:13:14 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Fri, 10 Oct 2025 17:33:53 GMT, Daniel Fuchs wrote: >> Mikhail Yankelevich 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 four additional commits since the last revision: >> >> - race condition fix >> - Merge branch 'master' into JDK-8368625 >> - race condition fix >> - JDK-8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 > > test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 164: > >> 162: // Complete the exchange 10 second into the future. >> 163: // Runs in parallel, so won't block the server stop >> 164: final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(10)); > > Looks good, but if this test fail we could envisage bumping that delay though. A better implementation could be to complete the exchange *after* exiting from server.stop() - without using any virtual thread, and just verifying that the server.stop() waited at least for 1s. The second temporal constraint is something that could possibly fail. If it fails why is it considered a test failure? Consider a slightly convoluted scenario: The Exchange will activate after 1 second. That thread is scheduled to execute but remains RTR due to excessive load on the system The server.stop is invoked with a 20 second delay, indicating this is the max allowed time for graceful shutdown i.e. the time in which any extant exchanges should complete. If that timeout expires in the finishLatch.await returns ? no check is made to determine if this was a timeout expiry or not ? then the server proceeds to shutdown. Thus, in this scenario, the test will fail. As such, how is this a failure? Your test has placed a temporal condition which has a possibility of not being met. Your expectation is that because the shutdown delay is 20 seconds the test should always pass, with the Exchange having completed, as such deterministic. This is not unreasonable, but it is not a condition that can be 100% met, and is not deterministic. The semantics of server.stop doesn?t consider a delay timeout as an error condition, so why is this the case in the test. So rather than it being a test failure, should a delay expiry just be observational ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2444705202 From heidinga at openjdk.org Mon Oct 20 13:56:45 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 20 Oct 2025 13:56:45 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65: > 63: > 64: // Static fields in this class are stateless, so the values initialized in the > 65: // AOT assembly phase can be safely cached. Looking through the implementations of the Access classes, and I have concerns about: `setJavaObjectInputFilterAccess` as it is implemented using a lambda: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well? `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445087494 From heidinga at openjdk.org Mon Oct 20 13:56:46 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 20 Oct 2025 13:56:46 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 13:51:18 GMT, Dan Heidinga wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65: > >> 63: >> 64: // Static fields in this class are stateless, so the values initialized in the >> 65: // AOT assembly phase can be safely cached. > > Looking through the implementations of the Access classes, and I have concerns about: > `setJavaObjectInputFilterAccess` as it is implemented using a lambda: > > SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); > > Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well? > > `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase. There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized. SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445095385 From dfuchs at openjdk.org Mon Oct 20 16:34:08 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Oct 2025 16:34:08 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v2] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 10:09:37 GMT, Volkan Yazici wrote: >> Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Update `module-info.java` docs It's an implementation specific property - so not part of the Java SE specification. IMO it was a bug that we didn't clamp it in the first place. There's no real change in observable behaviour here. I am not sure we actually need a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27874#issuecomment-3422837828 From dfuchs at openjdk.org Mon Oct 20 16:42:07 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Oct 2025 16:42:07 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v2] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 10:09:37 GMT, Volkan Yazici wrote: >> Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Update `module-info.java` docs src/java.net.http/share/classes/module-info.java line 54: > 52: * client. It accepts values between 1 and 2^14 (16384), including both > 53: * extremums. Values outside this range will be discarded and substituted with > 54: * the default. Suggestion: * The capacity of internal ephemeral buffers allocated to pass data to and from the * client, in bytes. Valid values are in the range [1, 2^14 (16384)]. * If an invalid value is provided, the default value is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2445552117 From dfuchs at openjdk.org Mon Oct 20 16:51:02 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Oct 2025 16:51:02 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Mon, 20 Oct 2025 11:10:50 GMT, Mark Sheppard wrote: >> test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 164: >> >>> 162: // Complete the exchange 10 second into the future. >>> 163: // Runs in parallel, so won't block the server stop >>> 164: final Duration exchangeDuration = Duration.ofSeconds(Utils.adjustTimeout(10)); >> >> Looks good, but if this test fail we could envisage bumping that delay though. A better implementation could be to complete the exchange *after* exiting from server.stop() - without using any virtual thread, and just verifying that the server.stop() waited at least for 1s. > > The second temporal constraint is something that could possibly fail. If it fails why is it considered a test failure? > > Consider a slightly convoluted scenario: > > The Exchange will activate after 1 second. That thread is scheduled to execute but remains RTR due to excessive load on the system > The server.stop is invoked with a 20 second delay, indicating this is the max allowed time for graceful shutdown i.e. the time in which any extant > exchanges should complete. If that timeout expires in the finishLatch.await returns ? no check is made to determine if this was a timeout expiry or not ? > then the server proceeds to shutdown. > > Thus, in this scenario, the test will fail. As such, how is this a failure? Your test has placed a temporal condition which has a possibility of not being met. > Your expectation is that because the shutdown delay is 20 seconds the test should always pass, with the Exchange having completed, as such deterministic. This > is not unreasonable, but it is not a condition that can be 100% met, and is not deterministic. > > The semantics of server.stop doesn?t consider a delay timeout as an error condition, so why is this the case in the test. > So rather than it being a test failure, should a delay expiry just be observational ? Was that a comment for the other test @msheppar - there's no 20s here. I still think a better impl would be to call completeExchange() after timeShutdown() here since we want to verify that the server will stop after the 1s delay even if an exchange is in progress. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2445569883 From iklam at openjdk.org Mon Oct 20 16:54:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 20 Oct 2025 16:54:03 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 13:53:52 GMT, Dan Heidinga wrote: >> src/java.base/share/classes/jdk/internal/access/SharedSecrets.java line 65: >> >>> 63: >>> 64: // Static fields in this class are stateless, so the values initialized in the >>> 65: // AOT assembly phase can be safely cached. >> >> Looking through the implementations of the Access classes, and I have concerns about: >> `setJavaObjectInputFilterAccess` as it is implemented using a lambda: >> >> SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); >> >> Correct me if I'm wrong, but I believe that will cause the `Config` class to be AOTInitialized as well? >> >> `Config` has a couple of system properties (-Djdk.serialFilter= for one) that we may not want to initialize during the assembly phase. > > There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized. > > SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); > SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445577257 From vyazici at openjdk.org Mon Oct 20 17:40:26 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 20 Oct 2025 17:40:26 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v3] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Apply property doc suggestion Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/148d4268..0cd7deef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From heidinga at openjdk.org Mon Oct 20 17:43:03 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 20 Oct 2025 17:43:03 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> On Mon, 20 Oct 2025 16:51:35 GMT, Ioi Lam wrote: >> There may be a similar issue with `ObjectInputStream` as well as I think this forces the class to be AOTInitialized. >> >> SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); >> SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); > > These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise? Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null? The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2445689913 From dfuchs at openjdk.org Mon Oct 20 17:52:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Oct 2025 17:52:03 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v3] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 17:40:26 GMT, Volkan Yazici wrote: >> Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Apply property doc suggestion > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> test/jdk/java/net/httpclient/BufferSize1Test.java line 108: > 106: if (response.statusCode() != 200) { > 107: throw new AssertionError("Was expecting status code 200, found: " + response.statusCode()); > 108: } It would be good to send at least two requests. I am not sure the test tests what it says it does - the HEAD request has no bodies in either ways. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2445707950 From msheppar at openjdk.org Mon Oct 20 17:40:01 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 20 Oct 2025 17:40:01 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Mon, 20 Oct 2025 16:47:50 GMT, Daniel Fuchs wrote: >> The second temporal constraint is something that could possibly fail. If it fails why is it considered a test failure? >> >> Consider a slightly convoluted scenario for shouldCompeteAfterDelay (the test which fails): >> >> The Exchange will activate after 1 second. That thread is scheduled to execute but remains RTR due to excessive load on the system >> The server.stop is invoked with a 20 second delay, indicating this is the max allowed time for graceful shutdown i.e. the time in which any extant >> exchanges should complete. If that timeout expires in the finishLatch.await returns ? no check is made to determine if this was a timeout expiry or not ? >> then the server proceeds to shutdown. >> >> Thus, in this scenario, the test will fail. As such, how is this a failure? Your test has placed a temporal condition which has a possibility of not being met. >> Your expectation is that because the shutdown delay is 20 seconds the test should always pass, with the Exchange having completed, as such deterministic. This >> is not unreasonable, but it is not a condition that can be 100% met, and is not deterministic. >> >> The semantics of server.stop doesn?t consider a delay timeout as an error condition, so why is this the case in the test. >> So rather than it being a test failure, should a delay expiry just be observational ? > > Was that a comment for the other test @msheppar - there's no 20s here. > I still think a better impl would be to call completeExchange() after timeShutdown() here since we want to verify that the server will stop after the 1s delay even if an exchange is in progress. it's shouldCompeteAfterDelay the test that fails final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(20)); log("Shutdown triggered with the delay of " + delayDuration.getSeconds()); final long elapsed = timeShutdown(delayDuration, startTime); log("Shutdown complete"); the shutdown delay has been increased to 20 seconds you are verifying that the server will stop after a max time of 20 seconds + (whatever time its takes to terminate whatever needs. to be terminated) The 1 seconds delay is to activate the Exchange and set it running ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2445683520 From dfuchs at openjdk.org Mon Oct 20 18:03:02 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 20 Oct 2025 18:03:02 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Mon, 20 Oct 2025 17:37:07 GMT, Mark Sheppard wrote: >> Was that a comment for the other test @msheppar - there's no 20s here. >> I still think a better impl would be to call completeExchange() after timeShutdown() here since we want to verify that the server will stop after the 1s delay even if an exchange is in progress. > > it's shouldCompeteAfterDelay the test that fails > > final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(20)); > log("Shutdown triggered with the delay of " + delayDuration.getSeconds()); > final long elapsed = timeShutdown(delayDuration, startTime); > log("Shutdown complete"); > > the shutdown delay has been increased to 20 seconds > > you are verifying that the server will stop after a max time of 20 seconds + (whatever time its takes to terminate whatever needs. to be terminated) > > The 1 seconds delay is to activate the Exchange and set it running The test that fails and has been updated with: final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(20)); is `shouldAwaitActiveExchange()` so I guess your comment was intended for `shouldAwaitAfterExchange()`. BTW @myankelev: in `shouldCompeteAfterDelay` is `compete` a typo? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2445733524 From msheppar at openjdk.org Mon Oct 20 18:10:03 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 20 Oct 2025 18:10:03 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Mon, 20 Oct 2025 18:00:26 GMT, Daniel Fuchs wrote: >> it's shouldAwaitActiveExchange the test that fails >> >> final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(20)); >> log("Shutdown triggered with the delay of " + delayDuration.getSeconds()); >> final long elapsed = timeShutdown(delayDuration, startTime); >> log("Shutdown complete"); >> >> the shutdown delay has been increased to 20 seconds >> >> you are verifying that the server will stop after a max time of 20 seconds + (whatever time its takes to terminate whatever needs. to be terminated) >> >> The 1 seconds delay is to activate the Exchange and set it running > > The test that fails and has been updated with: > > > final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(20)); > > > is `shouldAwaitActiveExchange()` so I guess your comment was intended for `shouldAwaitAfterExchange()`. > > BTW @myankelev: in `shouldCompeteAfterDelay` is `compete` a typo? apologies I got my cut and paste all wrong shouldAwaitActiveExchange ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2445747271 From vyazici at openjdk.org Tue Oct 21 08:12:51 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 21 Oct 2025 08:12:51 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v4] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? 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 five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into bufSizeClamp - Switch to POST and repeated-request in `BufferSize1Test` - Apply property doc suggestion Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> - Update `module-info.java` docs - Clamp `Utils::BUFSIZE` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/0cd7deef..26fdcb4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=02-03 Stats: 6032 lines in 184 files changed: 3763 ins; 1095 del; 1174 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From vyazici at openjdk.org Tue Oct 21 08:12:53 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 21 Oct 2025 08:12:53 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v3] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 17:49:23 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply property doc suggestion >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > > test/jdk/java/net/httpclient/BufferSize1Test.java line 108: > >> 106: if (response.statusCode() != 200) { >> 107: throw new AssertionError("Was expecting status code 200, found: " + response.statusCode()); >> 108: } > > It would be good to send at least two requests. > I am not sure the test tests what it says it does - the HEAD request has no bodies in either ways. In 5e839d409, updated the test to use POST and executed the request twice. > It would be good to send at least two requests. @dfuch, mind sharing what does this exactly help with? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2447159095 From dfuchs at openjdk.org Tue Oct 21 09:30:08 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 09:30:08 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 [v2] In-Reply-To: References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Mon, 20 Oct 2025 18:07:39 GMT, Mark Sheppard wrote: >> The test that fails and has been updated with: >> >> >> final Duration delayDuration = Duration.ofSeconds(Utils.adjustTimeout(20)); >> >> >> is `shouldAwaitActiveExchange()` so I guess your comment was intended for `shouldAwaitAfterExchange()`. >> >> BTW @myankelev: in `shouldCompeteAfterDelay` is `compete` a typo? > > apologies I got my cut and paste all wrong > > shouldAwaitActiveExchange All clear then! :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2447468921 From dfuchs at openjdk.org Tue Oct 21 09:34:14 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 09:34:14 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v3] In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 17:49:23 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply property doc suggestion >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > > test/jdk/java/net/httpclient/BufferSize1Test.java line 108: > >> 106: if (response.statusCode() != 200) { >> 107: throw new AssertionError("Was expecting status code 200, found: " + response.statusCode()); >> 108: } > > It would be good to send at least two requests. > I am not sure the test tests what it says it does - the HEAD request has no bodies in either ways. @dfuch, mind sharing what does this exactly help with? Remember the h2c upgrade? The first request is upgrading, the second is upgraded. That takes different paths. Also the first request always establishes the connection, the second reuses it. That's also a different path. Different paths don't necessary means that the code that use bufsize will be different, but it could mean different timing, different places where exceptions might get caught and propagated (if any). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2447487266 From dfuchs at openjdk.org Tue Oct 21 09:45:15 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 09:45:15 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v4] In-Reply-To: References: Message-ID: <7KFNjlLz_2qVatXmvZoR1PVZZCb-AkjrvEISOLYpfjs=.1b79c042-e869-4b0c-b423-59c5127c15bc@github.com> On Tue, 21 Oct 2025 08:12:51 GMT, Volkan Yazici wrote: >> Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? > > 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 five additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into bufSizeClamp > - Switch to POST and repeated-request in `BufferSize1Test` > - Apply property doc suggestion > > Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> > - Update `module-info.java` docs > - Clamp `Utils::BUFSIZE` test/jdk/java/net/httpclient/BufferSize1Test.java line 143: > 141: } > 142: > 143: private static final class BodyEchoingHandler implements HttpServerAdapters.HttpTestHandler { You could simply use / extend the HttpServerAdapters.HttpTestEchoHandler; Also consider implementing HttpServerAdapters in the test class to get rid of the leading HttpServerAdapters qualifier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2447515837 From dfuchs at openjdk.org Tue Oct 21 13:16:32 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 13:16:32 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v2] In-Reply-To: References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Tue, 21 Oct 2025 09:27:02 GMT, Daniel Fuchs wrote: >> apologies I got my cut and paste all wrong >> >> shouldAwaitActiveExchange > > All clear then! :-) Continuing the thread here although it belongs to other test: > The second temporal constraint is something that could possibly fail. If it fails why is it considered a test failure? if (elapsed >= delayDuration.toNanos()) { fail("HttpServer.stop terminated after delay expired"); } You are absolutely right - this can fail. We're taking a x20 margin though - so I would expect the occurrences should be very infrequent (if ever). That is - the server should be able to stop after the exchange complete - and the exchange is configured to complete after 1s - while the server stop waits for at most 20s. If more than 20s elapse between the time we take the startTime snapshot, and the time the server exits from stop, then the test will fail. This could happen - if for instance you do Thread.sleep(20) before calling `timeShutdown`. So this check is not reliable. However - it should be unlikely. I will import this PR and do some more testing. I am tempted to suggest that we should still fail in this case, but possibly change the message: - fail("HttpServer.stop terminated after delay expired"); + // this comparison is not 100% reliable and could fail if the main thread + // was premempted for long enough. We could raise `delayDuration` again + // to make it less likely. + fail("HttpServer.stop terminated after delay expired. Consider raising `delayDuration` to avoid intermittent failures"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2448216584 From michaelm at openjdk.org Tue Oct 21 15:04:27 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 21 Oct 2025 15:04:27 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v13] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 20:07:44 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Fix assertion statement in ExchangeAttributeTest src/jdk.httpserver/share/classes/module-info.java line 27: > 25: > 26: import module jdk.httpserver; > 27: The statement above seems to be causing a NullPointerException in the javadoc tool. I've filed a bug on it to find out what we need to do. But, it may mean reverting to "import com.sun.net.httpserver.*;" Also, the two implNotes are combined in the output HTML. So I would re-order them so the existing one comes first. In the meantime I will file a CSR with the additional doc text below ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448681838 From duke at openjdk.org Tue Oct 21 15:14:48 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 21 Oct 2025 15:14:48 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v14] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Refactor module-info.java for imports and notes Updated import statement and modified implementation notes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/c59d541d..d250e34d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=12-13 Stats: 18 lines in 1 file changed: 8 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From dfuchs at openjdk.org Tue Oct 21 15:46:55 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 15:46:55 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v14] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 15:14:48 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Refactor module-info.java for imports and notes > > Updated import statement and modified implementation notes. Changes requested by dfuchs (Reviewer). src/jdk.httpserver/share/classes/sun/net/httpserver/ExchangeImpl.java line 2: > 1: /* > 2: * Copyright (c) 2005, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved. test/jdk/com/sun/net/httpserver/ExchangeAttributePerExchangeTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. test/jdk/com/sun/net/httpserver/ExchangeAttributePerExchangeTest.java line 29: > 27: * @summary Test HttpExchange set/getAttribute do not affect HttpContext attributes > 28: * @library /test/lib > 29: * @run junit/othervm ExchangeAttributePerExchangeTest Suggestion: * @run junit/othervm ExchangeAttributePerExchangeTest * @run junit/othervm -Djdk.httpserver.attributes=context ExchangeAttributePerExchangeTest * @run junit/othervm -Djdk.httpserver.attributes=random-string ExchangeAttributePerExchangeTest * @run junit/othervm -Djdk.httpserver.attributes ExchangeAttributePerExchangeTest test/jdk/com/sun/net/httpserver/ExchangeAttributePerExchangeTest.java line 109: > 107: assertNotEquals("val", exchange.getHttpContext().getAttributes().get("attr")); > 108: exchange.setAttribute("attr", null); > 109: assertNull(exchange.getAttribute("attr")); Suggestion: assertNull(exchange.getAttribute("attr")); assertEquals("context-val", exchange.getHttpContext().getAttributes().get("attr")); test/jdk/com/sun/net/httpserver/ExchangeAttributePerExchangeTest.java line 117: > 115: } > 116: } > 117: } Please add newline at the end test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved. test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 72: > 70: @Test > 71: public void testExchangeAttributes() throws Exception { > 72: System.getProperty("jdk.httpserver.attributes", "context") I am suspecting `System.setProperty()` was intended here. Since the property is only consulted once in a static analyzer then using `System.setProperty()` is not appropriate. Instead the property should passed on the command line. And I think it would be better to test the effect of the property in your new test, rathar than here. ------------- PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3361381907 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448759770 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448757328 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448824400 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448776861 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448781343 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448788295 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448818096 From dfuchs at openjdk.org Tue Oct 21 15:46:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 15:46:56 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v14] In-Reply-To: References: Message-ID: On Tue, 21 Oct 2025 15:43:24 GMT, Daniel Fuchs wrote: >> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor module-info.java for imports and notes >> >> Updated import statement and modified implementation notes. > > test/jdk/com/sun/net/httpserver/ExchangeAttributePerExchangeTest.java line 29: > >> 27: * @summary Test HttpExchange set/getAttribute do not affect HttpContext attributes >> 28: * @library /test/lib >> 29: * @run junit/othervm ExchangeAttributePerExchangeTest > > Suggestion: > > * @run junit/othervm ExchangeAttributePerExchangeTest > * @run junit/othervm -Djdk.httpserver.attributes=context ExchangeAttributePerExchangeTest > * @run junit/othervm -Djdk.httpserver.attributes=random-string ExchangeAttributePerExchangeTest > * @run junit/othervm -Djdk.httpserver.attributes ExchangeAttributePerExchangeTest Then also modify the AttribHandler::exchange to consult the property and react appropriately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448827197 From dfuchs at openjdk.org Tue Oct 21 15:56:13 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 15:56:13 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v14] In-Reply-To: References: Message-ID: <9r0ckpnt8QVFURDIuvavGMkT8XpTDvoFrmoZ-EP2nRA=.be4850d0-c5d7-42e0-b7b3-bd83ac4694d7@github.com> On Tue, 21 Oct 2025 15:14:48 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Refactor module-info.java for imports and notes > > Updated import statement and modified implementation notes. Additional feedback - do we really need two tests? I hadn't realised that they were basically the same. I suggest to merge them (and keep the old name) test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 107: > 105: exchange.setAttribute("attr", "val"); > 106: assertEquals("val", exchange.getAttribute("attr")); > 107: assertEquals("val", exchange.getHttpContext().getAttributes().get("attr")); Suggestion: assertEquals("context-val", exchange.getHttpContext().getAttributes().get("attr")); ------------- Changes requested by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3361503304 PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2448845528 From duke at openjdk.org Tue Oct 21 16:02:30 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 21 Oct 2025 16:02:30 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v14] In-Reply-To: <9r0ckpnt8QVFURDIuvavGMkT8XpTDvoFrmoZ-EP2nRA=.be4850d0-c5d7-42e0-b7b3-bd83ac4694d7@github.com> References: <9r0ckpnt8QVFURDIuvavGMkT8XpTDvoFrmoZ-EP2nRA=.be4850d0-c5d7-42e0-b7b3-bd83ac4694d7@github.com> Message-ID: On Tue, 21 Oct 2025 15:53:03 GMT, Daniel Fuchs wrote: > Additional feedback - do we really need two tests? I hadn't realised that they were basically the same. I suggest to merge them (and keep the old name) basically, I didn't know you could do things like `@run junit/othervm -Djdk.httpserver.attributes ExchangeAttributePerExchangeTest`. I will consolidate them ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3427407222 From dfuchs at openjdk.org Tue Oct 21 16:08:43 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 16:08:43 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v14] In-Reply-To: References: <9r0ckpnt8QVFURDIuvavGMkT8XpTDvoFrmoZ-EP2nRA=.be4850d0-c5d7-42e0-b7b3-bd83ac4694d7@github.com> Message-ID: On Tue, 21 Oct 2025 15:59:17 GMT, Josiah Noel wrote: > basically, I didn't know you could do things like `@run junit/othervm -Djdk.httpserver.attributes ExchangeAttributePerExchangeTest`. I will consolidate them Oh! I understand now. Yes it would be good to consolidate everything in the existing test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3427448019 From vyazici at openjdk.org Tue Oct 21 17:47:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 21 Oct 2025 17:47:12 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v5] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Use `HttpTestEchoHandler` and improve styling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/26fdcb4a..92f07382 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=03-04 Stats: 29 lines in 1 file changed: 6 ins; 19 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From vyazici at openjdk.org Tue Oct 21 17:51:48 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 21 Oct 2025 17:51:48 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v4] In-Reply-To: <7KFNjlLz_2qVatXmvZoR1PVZZCb-AkjrvEISOLYpfjs=.1b79c042-e869-4b0c-b423-59c5127c15bc@github.com> References: <7KFNjlLz_2qVatXmvZoR1PVZZCb-AkjrvEISOLYpfjs=.1b79c042-e869-4b0c-b423-59c5127c15bc@github.com> Message-ID: On Tue, 21 Oct 2025 09:42:56 GMT, Daniel Fuchs 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 five additional commits since the last revision: >> >> - Merge remote-tracking branch 'upstream/master' into bufSizeClamp >> - Switch to POST and repeated-request in `BufferSize1Test` >> - Apply property doc suggestion >> >> Co-authored-by: Daniel Fuchs <67001856+dfuch at users.noreply.github.com> >> - Update `module-info.java` docs >> - Clamp `Utils::BUFSIZE` > > test/jdk/java/net/httpclient/BufferSize1Test.java line 143: > >> 141: } >> 142: >> 143: private static final class BodyEchoingHandler implements HttpServerAdapters.HttpTestHandler { > > You could simply use / extend the HttpServerAdapters.HttpTestEchoHandler; > Also consider implementing HttpServerAdapters in the test class to get rid of the leading HttpServerAdapters qualifier. `HttpTestEchoHandler` is a nice tip! In 92f07382f12, employed it and along with styling changes to remove all `HttpServerAdapters` qualifiers. I'll go with importing whatever I need from `HttpServerAdapters`. I am uncomfortable with extending from `HttpServerAdapters` since its API surface is vast and certain method calls (e.g., `createClientBuilderFor()`) still must be qualified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2449199282 From dfuchs at openjdk.org Tue Oct 21 17:56:37 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 21 Oct 2025 17:56:37 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v4] In-Reply-To: References: <7KFNjlLz_2qVatXmvZoR1PVZZCb-AkjrvEISOLYpfjs=.1b79c042-e869-4b0c-b423-59c5127c15bc@github.com> Message-ID: <5GG6HIs7uZPP3cjLbSXvYs8eN4Xu9xlpIe6ua9q16TU=.73f5c7d2-5c34-40af-8ef2-aace2e3a07e9@github.com> On Tue, 21 Oct 2025 17:48:56 GMT, Volkan Yazici wrote: >> test/jdk/java/net/httpclient/BufferSize1Test.java line 143: >> >>> 141: } >>> 142: >>> 143: private static final class BodyEchoingHandler implements HttpServerAdapters.HttpTestHandler { >> >> You could simply use / extend the HttpServerAdapters.HttpTestEchoHandler; >> Also consider implementing HttpServerAdapters in the test class to get rid of the leading HttpServerAdapters qualifier. > > `HttpTestEchoHandler` is a nice tip! In 92f07382f12, employed it and along with styling changes to remove all `HttpServerAdapters` qualifiers. > > I'll go with importing whatever I need from `HttpServerAdapters`. I am uncomfortable with extending from `HttpServerAdapters` since its API surface is vast and certain method calls (e.g., `createClientBuilderFor()`) still must be qualified. If you implement HttpServerAdapters which is what almost all other tests do then you can use `newClientBuilderForH3()` which is an instance method and does not need to be qualified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2449215385 From vyazici at openjdk.org Tue Oct 21 18:36:27 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 21 Oct 2025 18:36:27 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v4] In-Reply-To: <5GG6HIs7uZPP3cjLbSXvYs8eN4Xu9xlpIe6ua9q16TU=.73f5c7d2-5c34-40af-8ef2-aace2e3a07e9@github.com> References: <7KFNjlLz_2qVatXmvZoR1PVZZCb-AkjrvEISOLYpfjs=.1b79c042-e869-4b0c-b423-59c5127c15bc@github.com> <5GG6HIs7uZPP3cjLbSXvYs8eN4Xu9xlpIe6ua9q16TU=.73f5c7d2-5c34-40af-8ef2-aace2e3a07e9@github.com> Message-ID: On Tue, 21 Oct 2025 17:53:39 GMT, Daniel Fuchs wrote: >> `HttpTestEchoHandler` is a nice tip! In 92f07382f12, employed it and along with styling changes to remove all `HttpServerAdapters` qualifiers. >> >> I'll go with importing whatever I need from `HttpServerAdapters`. I am uncomfortable with extending from `HttpServerAdapters` since its API surface is vast and certain method calls (e.g., `createClientBuilderFor()`) still must be qualified. > > If you implement HttpServerAdapters which is what almost all other tests do then you can use `newClientBuilderForH3()` which is an instance method and does not need to be qualified. But neither `createClient()`, nor `main()` is an instance method ? both are static. Hence, `newClientBuilderForH3()` is inaccessible and needs to be qualified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2449332949 From duke at openjdk.org Tue Oct 21 18:42:11 2025 From: duke at openjdk.org (Josiah Noel) Date: Tue, 21 Oct 2025 18:42:11 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v15] In-Reply-To: References: Message-ID: <0vuO93YRqHcjOuPF6eFdy4qYxlzc1Hi3m-nyBby9Qyk=.c4b6d8fd-d5da-4d6e-80d9-8c0bfb43de10@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with two additional commits since the last revision: - Update ExchangeAttributeTest.java - pr comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/d250e34d..3e9a247e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=13-14 Stats: 138 lines in 3 files changed: 13 ins; 118 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From vyazici at openjdk.org Wed Oct 22 07:56:38 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 07:56:38 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v6] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? Volkan Yazici has updated the pull request incrementally with two additional commits since the last revision: - Document the rationale for a separate process in `BufferSizePropertyClampTest` - Convert `BufferSize1Test` to JUnit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/92f07382..b9186533 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=04-05 Stats: 50 lines in 2 files changed: 21 ins; 9 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From dfuchs at openjdk.org Wed Oct 22 08:41:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Oct 2025 08:41:58 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v4] In-Reply-To: References: <7KFNjlLz_2qVatXmvZoR1PVZZCb-AkjrvEISOLYpfjs=.1b79c042-e869-4b0c-b423-59c5127c15bc@github.com> <5GG6HIs7uZPP3cjLbSXvYs8eN4Xu9xlpIe6ua9q16TU=.73f5c7d2-5c34-40af-8ef2-aace2e3a07e9@github.com> Message-ID: On Tue, 21 Oct 2025 18:33:26 GMT, Volkan Yazici wrote: >> If you implement HttpServerAdapters which is what almost all other tests do then you can use `newClientBuilderForH3()` which is an instance method and does not need to be qualified. > > But neither `createClient()`, nor `main()` is an instance method ? both are static. Hence, `newClientBuilderForH3()` is inaccessible and needs to be qualified. oh right - this is not a testng/junit test... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27874#discussion_r2450941963 From vyazici at openjdk.org Wed Oct 22 09:07:33 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 09:07:33 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v7] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Replace separate process with a JUL handler in `BufferSizePropertyClampTest` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/b9186533..ab7695ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=05-06 Stats: 77 lines in 1 file changed: 32 ins; 20 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From vyazici at openjdk.org Wed Oct 22 09:15:29 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 09:15:29 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v8] In-Reply-To: References: Message-ID: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Remove redundant `throws Exception` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27874/files - new: https://git.openjdk.org/jdk/pull/27874/files/ab7695ec..e1a89493 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27874&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27874.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27874/head:pull/27874 PR: https://git.openjdk.org/jdk/pull/27874 From dfuchs at openjdk.org Wed Oct 22 09:15:30 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Oct 2025 09:15:30 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v8] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 09:11:45 GMT, Volkan Yazici wrote: >> Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant `throws Exception` LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27874#pullrequestreview-3364540118 From d.yamazaki at peya.tokyo Wed Oct 22 11:23:23 2025 From: d.yamazaki at peya.tokyo (Daisuke Yamazaki) Date: Wed, 22 Oct 2025 20:23:23 +0900 Subject: Proposal: 8355572: Implement Range header support for jwebserver Message-ID: <19a0ba8cd9b.3fb106283873448.4224658453221077600@peya.tokyo> Hello all, I would like to work on implementing Range header support for jwebserver, related to JDK-8355572. Before I start working on it, i'd like to confirm whether it's okay for me to take this issue. Here's my current design idea: 1. Introduce a RangeEntry record inside FileServerHandler to represent each requested range 2. In FileServerHandler.serveFile(), detect the Range header and parse it into a list of RangeEntry objects. If parsing fails or the range is invalid, return 416 Range Not Satisfiable. 3. If multiple ranges are specified, generate a random boundary string and return a multipart/byteranges response. Please let me know if it?s okay for me to proceed with this implementation, or if there are any design points I should consider before starting. Thanks, D. Yamazak From vyazici at openjdk.org Wed Oct 22 11:24:10 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:24:10 GMT Subject: RFR: 8367976: Validate and clamp jdk.httpclient.bufsize [v2] In-Reply-To: References: Message-ID: <6rYEMIk4KbQK3TwbAljOuZOOewDr_jEgV1RTSszF-yk=.a36ed9d8-ad37-4760-90fb-f6a454d65527@github.com> On Mon, 20 Oct 2025 16:31:48 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Update `module-info.java` docs > > It's an implementation specific property - so not part of the Java SE specification. IMO it was a bug that we didn't clamp it in the first place. There's no real change in observable behaviour here. I am not sure we actually need a CSR. @dfuch, thanks so much for the review feedback ? it, as always, certainly helped. Tier 1-2 is clear on several platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27874#issuecomment-3431878179 From vyazici at openjdk.org Wed Oct 22 11:24:12 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:24:12 GMT Subject: Integrated: 8367976: Validate and clamp jdk.httpclient.bufsize In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 18:36:39 GMT, Volkan Yazici wrote: > Validate and clamp the value populated from the `jdk.httpclient.bufsize` system property. Added two new tests: Does clamping work? Does the minimum value wedge the client? This pull request has now been integrated. Changeset: cbbb0a86 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/cbbb0a8630c991ba3a9e703ace47b479e944ce27 Stats: 289 lines in 5 files changed: 274 ins; 10 del; 5 mod 8367976: Validate and clamp jdk.httpclient.bufsize Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27874 From jpai at openjdk.org Wed Oct 22 11:37:46 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Oct 2025 11:37:46 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v5] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 05:37:45 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Revert `AbstractThrowingPublishers` changes src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 981: > 979: // Exceptions are often thrown from asynchronous code, making it > 980: // difficult to trace back to the user's original entry point. > 981: // Wrap exceptions explicitly to preserve that context. Nit - Would it better to reword this as: > // Exceptions are often thrown from asynchronous code, and the // stacktrace may not always contain the application classes. // That makes it difficult to trace back to the application code which // invoked the HttpClient. Here we instantiate/recreate the // exceptions to capture the application's calling code in the // stacktrace of the thrown exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2451787001 From vyazici at openjdk.org Wed Oct 22 11:54:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:31 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body Message-ID: 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!) ------------- Commit messages: - Improve docs as suggested by Rajan - Merge remote-tracking branch 'upstream/master' into respBodyTime - Fix code typo - Move `TimerCancellingBodyHandlerWrapper` logic to `HttpBodySubscriberWrapper` - Update documentation - Merge remote-tracking branch 'upstream/master' into respBodyTime - Check the entire causal chain to verify `HttpTimeoutException` - Reset timer on retried/forwarded requests - Improve `assertInstanceOf` statements - Fix timer leak (detected by `RedirectTimeoutTest`) - ... and 10 more: https://git.openjdk.org/jdk/compare/f158451c...29e0cdee Changes: https://git.openjdk.org/jdk/pull/27469/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8208693 Stats: 917 lines in 14 files changed: 858 ins; 12 del; 47 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 duke at openjdk.org Wed Oct 22 11:54:31 2025 From: duke at openjdk.org (Konrad Windszus) Date: Wed, 22 Oct 2025 11:54:31 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:24:35 GMT, Volkan Yazici 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!) @vy Thanks a lot for driving this. I think also the javadoc of the request timeout should be clarified with what timeframe exactly it refers to. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27469#issuecomment-3397015424 From vyazici at openjdk.org Wed Oct 22 11:54:32 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:32 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Mon, 13 Oct 2025 11:02:51 GMT, Konrad Windszus 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!) > > @vy Thanks a lot for driving this. I think also the javadoc of the request timeout should be clarified with what timeframe exactly it refers to. @kwin, thanks for your kind words. We really appreciate your feedback on `HttpClient`. I'm glad to see you even cross-linked other Issues/PRs from other projects. This really helps us with prioritizing tasks. If you have any feedback regarding `HttpClient`, you're most welcome to [the OpenJDK `net-dev` mailing list](https://mail.openjdk.org/mailman/listinfo/net-dev). > I think also the javadoc of the request timeout should be clarified with what timeframe exactly it refers to. Thanks for pointing this out. I gave it a shot in 6615e3ab3, though this is a delicate subject, and the script will probably be amended by others' comments. And before I forget... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27469#issuecomment-3406071056 From rhalade at openjdk.org Wed Oct 22 11:54:34 2025 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 22 Oct 2025 11:54:34 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:24:35 GMT, Volkan Yazici 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!) src/java.net.http/share/classes/java/net/http/HttpClient.java line 315: > 313: * implementation should apply it over the duration measured from the > 314: * instant a connection is requested to the instant that one is > 315: * established. This duration includes SSL handshakes, if required. Suggestion: * When a connection timeout is configured, an {@link HttpClient} implementation * applies it to the entire connection phase, from the moment a connection is * requested until it is established. The elapsed time includes any SSL/TLS handshake. src/java.net.http/share/classes/java/net/http/HttpRequest.java line 265: > 263: * > 264: * @implSpec > 265: * When a timeout value is present, an {@link HttpClient} Replace "When a timeout value is present" to "When a timeout is configured" for clarity in all occurrences in update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2436952270 PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2436967724 From vyazici at openjdk.org Wed Oct 22 11:54:35 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:35 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 18:00:00 GMT, Rajan Halade 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!) > > src/java.net.http/share/classes/java/net/http/HttpClient.java line 315: > >> 313: * implementation should apply it over the duration measured from the >> 314: * instant a connection is requested to the instant that one is >> 315: * established. This duration includes SSL handshakes, if required. > > Suggestion: > > * When a connection timeout is configured, an {@link HttpClient} implementation > * applies it to the entire connection phase, from the moment a connection is > * requested until it is established. The elapsed time includes any SSL/TLS handshake. Updated as requested in 29e0cdee3ac. > src/java.net.http/share/classes/java/net/http/HttpRequest.java line 265: > >> 263: * >> 264: * @implSpec >> 265: * When a timeout value is present, an {@link HttpClient} > > Replace "When a timeout value is present" to "When a timeout is configured" for clarity in all occurrences in update. Updated as requested in 29e0cdee3ac. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2447418290 PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2447417450 From vyazici at openjdk.org Wed Oct 22 11:54:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:37 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:24:35 GMT, Volkan Yazici 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!) src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java line 1341: > 1339: if (!responseReceived && resetError == Http3Error.H3_REQUEST_REJECTED) { > 1340: exchange.markUnprocessedByPeer(); > 1341: } Without this, server handler's `exchange.resetStream(Http3Error.H3_REQUEST_REJECTED.code())` results in client to fail the request, instead of retrying it. I am not sure if `H3_REQUEST_REJECTED` is the only error code we should guard against. src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 537: > 535: if (currentreq.timeout().isPresent()) { > 536: // Retried/Forwarded requests should reset the timer, if present > 537: cancelTimer(); In `master` (i.e., without this change), retried (due to some failure) and forwarded (due to 3XX responses with a `Location` header) requests will reset the timer at each retry and forwarding, respectively. This PR preserves this behavior, while additionally extending the request timeout's scope to cover _the complete retrieval_ of the response body too. But I would like to open this to discussion: 1. Shall we preserve the existing behavior and reset the timer on retries/forwarding? 2. Shall we ensure an `HttpClient::send` never exceeds the configured timeout even when there are retries/forwarding? 4. Something else? Note that the 1st option (i.e., the current behavior) implies that, if I configure a client to take max. 30 seconds for a request, I can be unfortunate enough to learn at production that it can actually take up to `5*30=150` seconds, where 5 is the default retry limit. That said, this behavior matches with Apache HTTP Client's [setResponseTimeout](https://hc.apache.org/httpcomponents-client-5.5.x/current/httpclient5/apidocs/org/apache/hc/client5/http/config/RequestConfig.Builder.html#setResponseTimeout-org.apache.hc.core5.util.Timeout-). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2392359322 PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2408186745 From vyazici at openjdk.org Wed Oct 22 11:54:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:37 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Tue, 30 Sep 2025 17:34:43 GMT, Volkan Yazici 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!) > > src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java line 1341: > >> 1339: if (!responseReceived && resetError == Http3Error.H3_REQUEST_REJECTED) { >> 1340: exchange.markUnprocessedByPeer(); >> 1341: } > > Without this, server handler's `exchange.resetStream(Http3Error.H3_REQUEST_REJECTED.code())` results in client to fail the request, instead of retrying it. I am not sure if `H3_REQUEST_REJECTED` is the only error code we should guard against. Figured the problem is more convoluted than it appears. @jaikiran will soon land a PR adressing this issue. I will hold this PR until then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2407905198 From vyazici at openjdk.org Wed Oct 22 11:54:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:37 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 18:37:14 GMT, Volkan Yazici wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/Http3ExchangeImpl.java line 1341: >> >>> 1339: if (!responseReceived && resetError == Http3Error.H3_REQUEST_REJECTED) { >>> 1340: exchange.markUnprocessedByPeer(); >>> 1341: } >> >> Without this, server handler's `exchange.resetStream(Http3Error.H3_REQUEST_REJECTED.code())` results in client to fail the request, instead of retrying it. I am not sure if `H3_REQUEST_REJECTED` is the only error code we should guard against. > > Figured the problem is more convoluted than it appears. @jaikiran will soon land a PR adressing this issue. I will hold this PR until then. [JDK-8369812] (_"HttpClient doesn't handle H3_REQUEST_REJECTED correctly"_) is created (along with #27793) to address this. [JDK-8369812]: https://bugs.openjdk.org/browse/JDK-8369812 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2428671551 From vyazici at openjdk.org Wed Oct 22 11:54:37 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:37 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:31:09 GMT, Volkan Yazici wrote: >> Figured the problem is more convoluted than it appears. @jaikiran will soon land a PR adressing this issue. I will hold this PR until then. > > [JDK-8369812] (_"HttpClient doesn't handle H3_REQUEST_REJECTED correctly"_) is created (along with #27793) to address this. > > [JDK-8369812]: https://bugs.openjdk.org/browse/JDK-8369812 Fixed in e857bcbdb. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2434914421 From michaelm at openjdk.org Wed Oct 22 11:54:39 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 22 Oct 2025 11:54:39 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 19:41:07 GMT, Volkan Yazici 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!) > > src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 537: > >> 535: if (currentreq.timeout().isPresent()) { >> 536: // Retried/Forwarded requests should reset the timer, if present >> 537: cancelTimer(); > > In `master` (i.e., without this change), retried (due to some failure) and forwarded (due to 3XX responses with a `Location` header) requests will reset the timer at each retry and forwarding, respectively. This PR preserves this behavior, while additionally extending the request timeout's scope to cover _the complete retrieval_ of the response body too. But I would like to open this to discussion: > > 1. Shall we preserve the existing behavior and reset the timer on retries/forwarding? > 2. Shall we ensure an `HttpClient::send` never exceeds the configured timeout even when there are retries/forwarding? > 4. Something else? > > Note that the 1st option (i.e., the current behavior) implies that, if I configure a client to take max. 30 seconds for a request, I can be unfortunate enough to learn at production that it can actually take up to `5*30=150` seconds, where 5 is the default retry limit. That said, this behavior matches with Apache HTTP Client's [setResponseTimeout](https://hc.apache.org/httpcomponents-client-5.5.x/current/httpclient5/apidocs/org/apache/hc/client5/http/config/RequestConfig.Builder.html#setResponseTimeout-org.apache.hc.core5.util.Timeout-). It would be very unusual for a server to wait 29 seconds before redirecting. I think you can assume that redirects will come in a reasonably timely fashion. The idea behind the timeout is really to allow for potentially large response bodies being downloaded and that's only going to happen once. So, a more likely scenario would be 1 or 2 seconds per redirect and then however long it takes to download the resource. So, in my opinion, the current behavior is okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2409632252 From vyazici at openjdk.org Wed Oct 22 11:54:40 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 22 Oct 2025 11:54:40 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: <_1mSJJRV8BwzBWyNq_hBwBNdJeC6JO5ydRHZIQBUMac=.d2902b07-b9c7-4617-85f4-c6c726c348a1@github.com> On Tue, 7 Oct 2025 07:16:01 GMT, Michael McMahon wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 537: >> >>> 535: if (currentreq.timeout().isPresent()) { >>> 536: // Retried/Forwarded requests should reset the timer, if present >>> 537: cancelTimer(); >> >> In `master` (i.e., without this change), retried (due to some failure) and forwarded (due to 3XX responses with a `Location` header) requests will reset the timer at each retry and forwarding, respectively. This PR preserves this behavior, while additionally extending the request timeout's scope to cover _the complete retrieval_ of the response body too. But I would like to open this to discussion: >> >> 1. Shall we preserve the existing behavior and reset the timer on retries/forwarding? >> 2. Shall we ensure an `HttpClient::send` never exceeds the configured timeout even when there are retries/forwarding? >> 4. Something else? >> >> Note that the 1st option (i.e., the current behavior) implies that, if I configure a client to take max. 30 seconds for a request, I can be unfortunate enough to learn at production that it can actually take up to `5*30=150` seconds, where 5 is the default retry limit. That said, this behavior matches with Apache HTTP Client's [setResponseTimeout](https://hc.apache.org/httpcomponents-client-5.5.x/current/httpclient5/apidocs/org/apache/hc/client5/http/config/RequestConfig.Builder.html#setResponseTimeout-org.apache.hc.core5.util.Timeout-). > > It would be very unusual for a server to wait 29 seconds before redirecting. I think you can assume that redirects will come in a reasonably timely fashion. The idea behind the timeout is really to allow for potentially large response bodies being downloaded and that's only going to happen once. So, a more likely scenario would be 1 or 2 seconds per redirect and then however long it takes to download the resource. So, in my opinion, the current behavior is okay. For the record, @djelinski and @dfuch also (internally) shared that the current behavior is okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2414379565 From jpai at openjdk.org Wed Oct 22 12:05:04 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Oct 2025 12:05:04 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 11:37:16 GMT, Daniel Fuchs wrote: >> Although it might look strange - we might want to wrap the UncheckedIOException instead of peeling it off. >> If the UncheckedIOException is generated by us (HttpClient implementation) then we most likely want to peel it off. But if it originates from custom code, peeling it off might hide important stack trace information. >> I am actually hesitating between the two possibilities. >> >> We see here that peeling of the UncheckedIOException from within sendAsync forces you to modify one test, where the UncheckedIOException was originating from custom code. I am not 100% sure we want do that. >> >> On the other hand - we don't want to add yet another version of toIOException. >> >> Let me think about this a bit more. > > OK - I think what you have is fine. Let's peel of UncheckedIOException. In most cases I could see the UncheckedIOException is only used to smugle an IOException, and in most case it's created at the point where the IOException is created too. That let me think that the extra stack trace will not be needed in most of the cases. We could revisit possibly later in a followup if we have reason to... I think, not propagating the original `UncheckedIOException` would be a bug. Imagine this application code: final Future> future = client.sendAsync(req, new BodyHandler() { @Override public BodySubscriber apply(ResponseInfo ri) { throw new UncheckedIOException("application specific message", new IOException("some other message")); } }); final HttpResponse resp; try { resp = future.get(); } catch (ExecutionException e) { final Throwable cause = e.getCause(); // cause must be UncheckedIOException and its message must be "application specific message" assert ... } I think the application should receive the `UncheckedIOException` as the top level cause of the `ExecutionException` and that `UncheckedIOException` must contain the original cause and the original message that was there when the application raised it. Not passing along that to the application, I think, would be wrong. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2451852130 From jpai at openjdk.org Wed Oct 22 12:13:32 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 22 Oct 2025 12:13:32 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v5] In-Reply-To: References: Message-ID: On Thu, 16 Oct 2025 05:37:45 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Revert `AbstractThrowingPublishers` changes test/jdk/java/net/httpclient/HttpClientSendAsyncExceptionTest.java line 72: > 70: var request = HttpRequest.newBuilder(URI.create("https://example.com")).GET().build(); > 71: var responseBodyHandler = HttpResponse.BodyHandlers.discarding(); > 72: client.sendAsync(request, responseBodyHandler).get(); Nit - it doesn't matter much in this code, but it's usually better to limit the code to the specific call that is expected to throw the expected exception type. That would mean moving out everything except the `Future.get()` call from the lambda. Same comment for the code in the other test methods too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2451875566 From dfuchs at openjdk.org Wed Oct 22 12:33:15 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Oct 2025 12:33:15 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body In-Reply-To: References: Message-ID: On Wed, 24 Sep 2025 13:24:35 GMT, Volkan Yazici 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!) src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 414: > 412: return handleNoBody(r, exch); > 413: } > 414: return exch.readBodyAsync(responseHandler, this::cancelTimer) Could we remove the `preTerminationCallback` parameter, and instead have the various subclass of `HttpBodySubscriberWrapper` supply `this.multi::cancelTimer()` to their super class? If I'm not mistaken all concrete subclasses of `HttpBodySubscriberWrapper` have access to the multi exchange. That should reduce the amount of changes significantly. Another possibility is to introduce a noarg protected abstract method in `HttpBodySubscriberWrapper` and have all subclasses implement it. We could call it for instance `protected abstract void onTerminationNotified();` and explain that it can be used to cancel a timer if needed. It might need to be called on cancel as well? If not a comment explaining why might be good to have. If it's not called by cancel then maybe the method suggested above could be changed to `onCompletionNotified`. src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 412: > 410: if (preTerminationCallback != null) { > 411: preTerminationCallback.run(); > 412: } Did you consider adding this to complete() instead? There would then be a single place where this code would appear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2451899504 PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2451927047 From dfuchs at openjdk.org Wed Oct 22 12:59:04 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Oct 2025 12:59:04 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:01:43 GMT, Jaikiran Pai wrote: >> OK - I think what you have is fine. Let's peel of UncheckedIOException. In most cases I could see the UncheckedIOException is only used to smugle an IOException, and in most case it's created at the point where the IOException is created too. That let me think that the extra stack trace will not be needed in most of the cases. We could revisit possibly later in a followup if we have reason to... > > I think, not propagating the original `UncheckedIOException` would be a bug. Imagine this application code: > > > final Future> future = client.sendAsync(req, new BodyHandler() { > @Override > public BodySubscriber apply(ResponseInfo ri) { > throw new UncheckedIOException("application specific message", new IOException("some other message")); > } > }); > final HttpResponse resp; > try { > resp = future.get(); > } catch (ExecutionException e) { > final Throwable cause = e.getCause(); > // cause must be UncheckedIOException and its message must be "application specific message" > assert ... > } > > I think the application should receive the `UncheckedIOException` as the top level cause of the `ExecutionException` and that `UncheckedIOException` must contain the original cause and the original message that was there when the application raised it. Not passing along that to the application, I think, would be wrong. Then we should wrap - but that could be strange. Especially in those cases where the application does: throw new UncheckedIOException(new IOException(msg)); But yes - maybe you're right. Since send() does rewrap UncheckedIOException into IOException then maybe sendAsync should do so too. Utils.toIOException could be overriden with a method that takes a lambda to convert UncheckedIOException to IOException. Something like: public static IOException toIOException(Throwable cause) { + return toIOException(cause, UncheckedIOException::getCause); + } + + public static IOException toIOException(Throwable cause, Function uncheckedIOConverter) { if (cause == null) return null; if (cause instanceof CompletionException ce) { cause = ce.getCause(); @@ -522,7 +526,7 @@ public static IOException toIOException(Throwable cause) { if (cause instanceof IOException io) { return io; } else if (cause instanceof UncheckedIOException uio) { - return uio.getCause(); + return uncheckedIOConverter.apply(uio); } return new IOException(cause.getMessage(), cause); } Then sendAsync could call `Utils.toIOException(throwable, IOException::new)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2452001406 From dfuchs at openjdk.org Wed Oct 22 14:48:39 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 22 Oct 2025 14:48:39 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v15] In-Reply-To: <0vuO93YRqHcjOuPF6eFdy4qYxlzc1Hi3m-nyBby9Qyk=.c4b6d8fd-d5da-4d6e-80d9-8c0bfb43de10@github.com> References: <0vuO93YRqHcjOuPF6eFdy4qYxlzc1Hi3m-nyBby9Qyk=.c4b6d8fd-d5da-4d6e-80d9-8c0bfb43de10@github.com> Message-ID: On Tue, 21 Oct 2025 18:42:11 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with two additional commits since the last revision: > > - Update ExchangeAttributeTest.java > - pr comments The new test is failing. It would be good to run tests locally before pushing commits to the PR. > test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java:117: error: ';' expected > assertEquals("val", exchange.getAttribute("attr")) > ^ > 1 error > result: Failed. Compilation failed: Compilation failed ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3432748969 From duke at openjdk.org Wed Oct 22 17:52:48 2025 From: duke at openjdk.org (Josiah Noel) Date: Wed, 22 Oct 2025 17:52:48 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v16] In-Reply-To: References: Message-ID: > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update ExchangeAttributeTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/3e9a247e..f7d9b3bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=14-15 Stats: 8 lines in 1 file changed: 2 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From ethan at mccue.dev Wed Oct 22 17:56:29 2025 From: ethan at mccue.dev (Ethan McCue) Date: Wed, 22 Oct 2025 13:56:29 -0400 Subject: Proposal: 8355572: Implement Range header support for jwebserver In-Reply-To: <19a0ba8cd9b.3fb106283873448.4224658453221077600@peya.tokyo> References: <19a0ba8cd9b.3fb106283873448.4224658453221077600@peya.tokyo> Message-ID: Adding for context that there are legitimate usages for this that are within the jdk httpserver's remit of jwebserver and educational purposes. Cheerpj would let a student run their java code in a browser and requires range headers support. On Wed, Oct 22, 2025, 7:23?AM Daisuke Yamazaki wrote: > Hello all, > > I would like to work on implementing Range header support for jwebserver, > related to JDK-8355572. > Before I start working on it, i'd like to confirm whether it's okay for me > to > take this issue. > > Here's my current design idea: > > 1. Introduce a RangeEntry record inside FileServerHandler to represent > each requested range > 2. In FileServerHandler.serveFile(), detect the Range header and parse it > into > a list of RangeEntry objects. > If parsing fails or the range is invalid, return 416 Range Not > Satisfiable. > 3. If multiple ranges are specified, generate a random boundary > string and return a multipart/byteranges response. > > Please let me know if it?s okay for me to proceed with this implementation, > or if there are any design points I should consider before starting. > > Thanks, > D. Yamazak > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Thu Oct 23 10:37:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 23 Oct 2025 10:37:05 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 12:56:03 GMT, Daniel Fuchs wrote: >> I think, not propagating the original `UncheckedIOException` would be a bug. Imagine this application code: >> >> >> final Future> future = client.sendAsync(req, new BodyHandler() { >> @Override >> public BodySubscriber apply(ResponseInfo ri) { >> throw new UncheckedIOException("application specific message", new IOException("some other message")); >> } >> }); >> final HttpResponse resp; >> try { >> resp = future.get(); >> } catch (ExecutionException e) { >> final Throwable cause = e.getCause(); >> // cause must be UncheckedIOException and its message must be "application specific message" >> assert ... >> } >> >> I think the application should receive the `UncheckedIOException` as the top level cause of the `ExecutionException` and that `UncheckedIOException` must contain the original cause and the original message that was there when the application raised it. Not passing along that to the application, I think, would be wrong. > > Then we should wrap - but that could be strange. Especially in those cases where the application does: > > throw new UncheckedIOException(new IOException(msg)); > > > But yes - maybe you're right. Since send() does rewrap UncheckedIOException into IOException then maybe sendAsync should do so too. Utils.toIOException could be overriden with a method that takes a lambda to convert UncheckedIOException to IOException. Something like: > > > public static IOException toIOException(Throwable cause) { > + return toIOException(cause, UncheckedIOException::getCause); > + } > + > + public static IOException toIOException(Throwable cause, Function uncheckedIOConverter) { > if (cause == null) return null; > if (cause instanceof CompletionException ce) { > cause = ce.getCause(); > @@ -522,7 +526,7 @@ public static IOException toIOException(Throwable cause) { > if (cause instanceof IOException io) { > return io; > } else if (cause instanceof UncheckedIOException uio) { > - return uio.getCause(); > + return uncheckedIOConverter.apply(uio); > } > return new IOException(cause.getMessage(), cause); > } > > > Then sendAsync could call `Utils.toIOException(throwable, IOException::new)` > I think the application should receive the UncheckedIOException as the top level cause of the ExecutionException and that UncheckedIOException Slight correction to that previous comment of mine. In my mind, for a moment I thought UncheckedIOException is a IOException and that's why I said it should be returned as a the instance from `ExecutionException.getCause()`. That's not the case and I think what should really happen is that we treat `UncheckedIOException` just like any other `RuntimeException` and wrap it into a `IOException`. I think we shouldn't be peeking into the `UncheckedIOException.getCause()` at all when constructing that top level `IOException`. That way we will correctly pass along the original exception that was raised by the application code. Very specifically, I think the `Utils.toIOException()` should look like: public static IOException toIOException(Throwable cause) { if (cause == null) return null; if (cause instanceof CompletionException ce) { cause = ce.getCause(); } else if (cause instanceof ExecutionException ee) { cause = ee.getCause(); } if (cause instanceof IOException io) { return io; } return new IOException(cause.getMessage(), cause); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2454672474 From dfuchs at openjdk.org Thu Oct 23 11:16:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Oct 2025 11:16:03 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 10:34:48 GMT, Jaikiran Pai wrote: >> Then we should wrap - but that could be strange. Especially in those cases where the application does: >> >> throw new UncheckedIOException(new IOException(msg)); >> >> >> But yes - maybe you're right. Since send() does rewrap UncheckedIOException into IOException then maybe sendAsync should do so too. Utils.toIOException could be overriden with a method that takes a lambda to convert UncheckedIOException to IOException. Something like: >> >> >> public static IOException toIOException(Throwable cause) { >> + return toIOException(cause, UncheckedIOException::getCause); >> + } >> + >> + public static IOException toIOException(Throwable cause, Function uncheckedIOConverter) { >> if (cause == null) return null; >> if (cause instanceof CompletionException ce) { >> cause = ce.getCause(); >> @@ -522,7 +526,7 @@ public static IOException toIOException(Throwable cause) { >> if (cause instanceof IOException io) { >> return io; >> } else if (cause instanceof UncheckedIOException uio) { >> - return uio.getCause(); >> + return uncheckedIOConverter.apply(uio); >> } >> return new IOException(cause.getMessage(), cause); >> } >> >> >> Then sendAsync could call `Utils.toIOException(throwable, IOException::new)` > >> I think the application should receive the UncheckedIOException as the top level cause of the ExecutionException and that UncheckedIOException > > Slight correction to that previous comment of mine. In my mind, for a moment I thought UncheckedIOException is a IOException and that's why I said it should be returned as a the instance from `ExecutionException.getCause()`. That's not the case and I think what should really happen is that we treat `UncheckedIOException` just like any other `RuntimeException` and wrap it into a `IOException`. I think we shouldn't be peeking into the `UncheckedIOException.getCause()` at all when constructing that top level `IOException`. That way we will correctly pass along the original exception that was raised by the application code. > > Very specifically, I think the `Utils.toIOException()` should look like: > > > public static IOException toIOException(Throwable cause) { > if (cause == null) return null; > if (cause instanceof CompletionException ce) { > cause = ce.getCause(); > } else if (cause instanceof ExecutionException ee) { > cause = ee.getCause(); > } > if (cause instanceof IOException io) { > return io; > } > return new IOException(cause.getMessage(), cause); > } Ok - let's do that. To my surprise there's only one place where toIOException is called. Other places that need an IO simply create a new IO. We could revisit those places and see if they should also call toIOException but that's another story best handled separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2454766162 From d.yamazaki at peya.tokyo Thu Oct 23 14:49:24 2025 From: d.yamazaki at peya.tokyo (Daisuke Yamazaki) Date: Thu, 23 Oct 2025 23:49:24 +0900 Subject: Proposal: 8355572: Implement Range header support for jwebserver In-Reply-To: References: <19a0ba8cd9b.3fb106283873448.4224658453221077600@peya.tokyo> Message-ID: <19a118bc8b8.2a6a9f384719417.6464960423018348784@peya.tokyo> Thank you for the clarification and context. I understand that there is a legitimate need for Range header support. However, whether such a feature is necessary for the simple jwebserver is still open for discussion. Nevertheless, while the benefits are clear, I do not see any significant drawbacks apart from potential maintainability or slight code growth. I personally think it would be reasonable to implement this feature. I plan to wait for a bit to allow further discussion, and if no objections arise, I intend to proceed with the implementation. ---- On Thu, 23 Oct 2025 02:56:29 +0900 Ethan McCue wrote --- > Adding for context that there are legitimate usages for this that are within the jdk httpserver's remit of jwebserver and educational purposes. Cheerpj would let a student run their java code in a browser and requires range headers support. > > On Wed, Oct 22, 2025, 7:23?AM Daisuke Yamazaki wrote: > > Hello all, > > I would like to work on implementing Range header support for jwebserver, > related to JDK-8355572. > Before I start working on it, i'd like to confirm whether it's okay for me to > take this issue. > > Here's my current design idea: > > 1. Introduce a RangeEntry record inside FileServerHandler to represent > each requested range > 2. In FileServerHandler.serveFile(), detect the Range header and parse it into > a list of RangeEntry objects. > If parsing fails or the range is invalid, return 416 Range Not Satisfiable. > 3. If multiple ranges are specified, generate a random boundary > string and return a multipart/byteranges response. > > Please let me know if it?s okay for me to proceed with this implementation, > or if there are any design points I should consider before starting. > > Thanks, > D. Yamazak > From daniel.fuchs at oracle.com Thu Oct 23 15:11:58 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 23 Oct 2025 16:11:58 +0100 Subject: Proposal: 8355572: Implement Range header support for jwebserver In-Reply-To: <19a118bc8b8.2a6a9f384719417.6464960423018348784@peya.tokyo> References: <19a0ba8cd9b.3fb106283873448.4224658453221077600@peya.tokyo> <19a118bc8b8.2a6a9f384719417.6464960423018348784@peya.tokyo> Message-ID: <39bd5959-187f-449d-8e70-e3ea914d410d@oracle.com> Hi, I would support investigating adding support for Range header in the FileServerHandler. In the HttpClient, we have recently added a new BodyPublishers.ofFileChannel() request publisher as a potential building block to ease implementation of partial/resumable file uploads in applications. We have nothing out of the box for resumable file downloads in the HttpClient API though. It would be good if you could use the HttpClient API in the unit tests you will develop. Maybe we could use that as an opportunity to learn whether some more building blocks of general utility could be added on the client side (in the future) to ease the implementation of applications that would have a need for Range headers, such as to implement a download manager for instance. best regards, -- daniel On 23/10/2025 15:49, Daisuke Yamazaki wrote: > Thank you for the clarification and context. > > I understand that there is a legitimate need for Range header support. > However, whether such a feature is necessary for the simple jwebserver is > still open for discussion. > > Nevertheless, while the benefits are clear, I do not see any significant > drawbacks apart from potential maintainability or slight code growth. > I personally think it would be reasonable to implement this feature. > > I plan to wait for a bit to allow further discussion, and if no objections > arise, I intend to proceed with the implementation. > > ---- On Thu, 23 Oct 2025 02:56:29 +0900 Ethan McCue wrote --- > > > Adding for context that there are legitimate usages for this that are within the jdk httpserver's remit of jwebserver and educational purposes. Cheerpj would let a student run their java code in a browser and requires range headers support. > > > > On Wed, Oct 22, 2025, 7:23?AM Daisuke Yamazaki wrote: > > > > Hello all, > > > > I would like to work on implementing Range header support for jwebserver, > > related to JDK-8355572. > > Before I start working on it, i'd like to confirm whether it's okay for me to > > take this issue. > > > > Here's my current design idea: > > > > 1. Introduce a RangeEntry record inside FileServerHandler to represent > > each requested range > > 2. In FileServerHandler.serveFile(), detect the Range header and parse it into > > a list of RangeEntry objects. > > If parsing fails or the range is invalid, return 416 Range Not Satisfiable. > > 3. If multiple ranges are specified, generate a random boundary > > string and return a multipart/byteranges response. > > > > Please let me know if it?s okay for me to proceed with this implementation, > > or if there are any design points I should consider before starting. > > > > Thanks, > > D. Yamazak > > > From dfuchs at openjdk.org Thu Oct 23 15:12:09 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 23 Oct 2025 15:12:09 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v16] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 17:52:48 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeAttributeTest.java Marked as reviewed by dfuchs (Reviewer). I have run tier2 with the latest changes in our CI and tests passed successfully. I have also run the whole :jdk_net several time in the CI and observed no intermittent failures. As far as I'm concerned things look good now. Michael has also finalized the CSR. ------------- PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3370499301 PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3437537356 From duke at openjdk.org Thu Oct 23 19:56:09 2025 From: duke at openjdk.org (duke) Date: Thu, 23 Oct 2025 19:56:09 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v16] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 17:52:48 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeAttributeTest.java @SentryMan Your change (at version f7d9b3bfc415dd23c6334f5b8464e9bd3e365ef9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3438872385 From jpai at openjdk.org Fri Oct 24 04:52:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Oct 2025 04:52:08 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v16] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 17:52:48 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeAttributeTest.java test/jdk/com/sun/net/httpserver/ExchangeAttributeTest.java line 115: > 113: assertEquals("context-val", exchange.getHttpContext().getAttributes().get("attr")); > 114: exchange.setAttribute("attr", "val"); > 115: assertEquals("val", exchange.getAttribute("attr")); I think it would be good to add an additional assert after this line to verify that the call to `exchange.setAttribute("attr", "val");` doesn't change the value in the context attributes. So something like: assertEquals("context-val", exchange.getHttpContext().getAttributes().get("attr")); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27652#discussion_r2458882677 From duke at openjdk.org Fri Oct 24 06:06:44 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 24 Oct 2025 06:06:44 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v17] In-Reply-To: References: Message-ID: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> > Now ExchangeImpl will default to having a separate attribute map for the request duration. Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: Update ExchangeAttributeTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27652/files - new: https://git.openjdk.org/jdk/pull/27652/files/f7d9b3bf..b5df11b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27652&range=15-16 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27652.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27652/head:pull/27652 PR: https://git.openjdk.org/jdk/pull/27652 From jpai at openjdk.org Fri Oct 24 06:20:04 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 24 Oct 2025 06:20:04 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v17] In-Reply-To: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> References: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> Message-ID: <9SX7PSIo4D9sZaH5IcHt2ASnEjhNQDKXvGwWFne93GE=.a0571f02-ae96-4bff-b591-90eef62e6205@github.com> On Fri, 24 Oct 2025 06:06:44 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeAttributeTest.java Thank you for the update, this looks good to me. I'll let Michael (and Daniel) have a chance to review the updated version. On a general note, since you are contributing to the `HttpServer` area, I would also recommend that you run `tier2` tests locally. The GitHub actions job for the JDK only runs tier1 and that tier doesn't cover the networking area. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3374705582 From myankelevich at openjdk.org Fri Oct 24 10:18:44 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 24 Oct 2025 10:18:44 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v2] In-Reply-To: <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> References: <2D4jHyvaNKgsL5DrgxUShzbkY8NlyfBJp_67dPUZMqs=.34c91bc7-71e7-428a-aaab-8c5893f7f8a0@github.com> <3j5JX2znaHVoHPjK5eHGzFHcpi8-fPz4h_9R7ZQIQz0=.17105cf1-efb4-4091-8b4c-d8ad2b20c3b0@github.com> Message-ID: On Fri, 10 Oct 2025 17:21:26 GMT, Daniel Fuchs wrote: >> Mikhail Yankelevich 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 four additional commits since the last revision: >> >> - race condition fix >> - Merge branch 'master' into JDK-8368625 >> - race condition fix >> - JDK-8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently in tier7 > > test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 127: > >> 125: // Complete the exchange one second into the future >> 126: final Duration exchangeDuration = Duration.ofSeconds(1); >> 127: final long startTime = System.nanoTime(); // taking custom start time just in case > > Suggestion: > > // taking start time before entering completeExchange to account for possible > // delays in reaching server.stop(). > final long startTime = System.nanoTime(); Done in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2459674960 From michaelm at openjdk.org Fri Oct 24 10:53:06 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 24 Oct 2025 10:53:06 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v17] In-Reply-To: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> References: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> Message-ID: <0gbZFy6PnXAqAhnqs0j1Lac5pTjbokbJ-tEpEYhTs4I=.a3ab956e-8b5f-4ee6-903e-336e4e1cec64@github.com> On Fri, 24 Oct 2025 06:06:44 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeAttributeTest.java LGTM ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27652#pullrequestreview-3375716352 From vyazici at openjdk.org Fri Oct 24 12:21:25 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 12:21:25 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values Message-ID: Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. ------------- Commit messages: - Add `DeadlineOverflowTest` - Fix duration overflows - Add `DurationOverflowTest` Changes: https://git.openjdk.org/jdk/pull/27973/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368528 Stats: 651 lines in 5 files changed: 593 ins; 34 del; 24 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 Fri Oct 24 12:21:27 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 12:21:27 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 12:10:38 GMT, Volkan Yazici wrote: > Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. src/java.net.http/share/classes/jdk/internal/net/http/HttpQuicConnection.java line 1: > 1: /* Addresses following failures: Caused by: java.lang.ArithmeticException: long overflow at java.base/java.lang.Math.multiplyExact(Math.java:1036) at java.base/java.lang.Math.multiplyExact(Math.java:1012) at java.base/java.time.Duration.toMillis(Duration.java:1243) at java.net.http/jdk.internal.net.http.HttpQuicConnection$H3QuicConnectionImpl.connectAsync(HttpQuicConnection.java:509) src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 1: > 1: /* Addresses two following failures: Caused by: java.time.DateTimeException: Instant exceeds minimum or maximum instant at java.base/java.time.Instant.plusSeconds(Instant.java:883) at java.base/java.time.Instant.plus(Instant.java:856) at java.base/java.time.Instant.plus(Instant.java:209) at java.base/java.time.Duration.addTo(Duration.java:1120) at java.base/java.time.Instant.plus(Instant.java:788) at java.net.http/jdk.internal.net.http.common.Deadline.plus(Deadline.java:177) Caused by: java.lang.ArithmeticException: long overflow at java.base/java.lang.Math.multiplyExact(Math.java:1036) at java.base/java.time.Instant.millisUntil(Instant.java:1207) at java.base/java.time.Instant.until(Instant.java:1153) at java.net.http/jdk.internal.net.http.common.Deadline.until(Deadline.java:200) test/jdk/java/net/httpclient/DurationOverflowTest.java line 257: > 255: Duration.MAX, > 256: // This triggers different exceptions than the ones triggered by `Duration.MAX` > 257: Duration.ofMillis(Long.MAX_VALUE)); The reproduction by the reporter provides 3 `Duration` values triggering failures. Above two is sufficient to reproduce all 3 exceptions shared earlier: 1. `plus(Deadline.java:177)` 2. `until(Deadline.java:200)` 3. `connectAsync(HttpQuicConnection.java:509)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2460116503 PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2460121100 PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2460135873 From duke at openjdk.org Fri Oct 24 13:07:06 2025 From: duke at openjdk.org (duke) Date: Fri, 24 Oct 2025 13:07:06 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v17] In-Reply-To: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> References: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> Message-ID: On Fri, 24 Oct 2025 06:06:44 GMT, Josiah Noel wrote: >> Now ExchangeImpl will default to having a separate attribute map for the request duration. > > Josiah Noel has updated the pull request incrementally with one additional commit since the last revision: > > Update ExchangeAttributeTest.java @SentryMan Your change (at version b5df11b804214648bcbf4f5eb3d97cdea1c481f2) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3443061274 From vyazici at openjdk.org Fri Oct 24 13:26:24 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 13:26:24 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v2] In-Reply-To: References: Message-ID: > Currently `HttpRequest::timeout` only applies until the response headers are received. Extend its scope to also cover the consumption of the response body. > > ### Review guidelines > > 1. Read _"the fix"_ in `MultiExchange` > 2. Skim through the test server *handler* in `TimeoutResponseTestSupport` > 3. Review first `TimeoutResponseHeaderTest`, and then `TimeoutResponseBodyTest` (Mind the multiple `@test` blocks!) Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Move `preTerminationCallback` to `complete()` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27469/files - new: https://git.openjdk.org/jdk/pull/27469/files/29e0cdee..bcd5bcc8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=00-01 Stats: 9 lines in 1 file changed: 3 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27469.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27469/head:pull/27469 PR: https://git.openjdk.org/jdk/pull/27469 From vyazici at openjdk.org Fri Oct 24 13:26:25 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 13:26:25 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v2] In-Reply-To: References: Message-ID: <8a1J67GOCEouBIA2iSanj3d3l1w669GyPhBIWBJNmmg=.2adf179b-4174-40f2-8cce-b28f53868fac@github.com> On Wed, 22 Oct 2025 12:30:59 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Move `preTerminationCallback` to `complete()` > > src/java.net.http/share/classes/jdk/internal/net/http/common/HttpBodySubscriberWrapper.java line 412: > >> 410: if (preTerminationCallback != null) { >> 411: preTerminationCallback.run(); >> 412: } > > Did you consider adding this to complete() instead? There would then be a single place where this code would appear. This not just simplifies the code, but also corrects it! `preTerminationCallback` should be called once. Implemented as suggested in bcd5bcc8a58. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2460440877 From vyazici at openjdk.org Fri Oct 24 14:42:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 14:42:41 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v6] In-Reply-To: References: Message-ID: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: - Avoid peeling off `UncheckedIOException` - Minimize bodies passed to `assertThrows()` - Improve `HttpClientImpl` comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27787/files - new: https://git.openjdk.org/jdk/pull/27787/files/f2fa01df..5621d911 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=04-05 Stats: 73 lines in 2 files changed: 4 ins; 3 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From vyazici at openjdk.org Fri Oct 24 14:42:45 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 14:42:45 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v3] In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 11:13:19 GMT, Daniel Fuchs wrote: >>> I think the application should receive the UncheckedIOException as the top level cause of the ExecutionException and that UncheckedIOException >> >> Slight correction to that previous comment of mine. In my mind, for a moment I thought UncheckedIOException is a IOException and that's why I said it should be returned as a the instance from `ExecutionException.getCause()`. That's not the case and I think what should really happen is that we treat `UncheckedIOException` just like any other `RuntimeException` and wrap it into a `IOException`. I think we shouldn't be peeking into the `UncheckedIOException.getCause()` at all when constructing that top level `IOException`. That way we will correctly pass along the original exception that was raised by the application code. >> >> Very specifically, I think the `Utils.toIOException()` should look like: >> >> >> public static IOException toIOException(Throwable cause) { >> if (cause == null) return null; >> if (cause instanceof CompletionException ce) { >> cause = ce.getCause(); >> } else if (cause instanceof ExecutionException ee) { >> cause = ee.getCause(); >> } >> if (cause instanceof IOException io) { >> return io; >> } >> return new IOException(cause.getMessage(), cause); >> } > > Ok - let's do that. To my surprise there's only one place where toIOException is called. Other places that need an IO simply create a new IO. We could revisit those places and see if they should also call toIOException but that's another story best handled separately. Pushed 5621d911944; it avoids peeling off `UncheckedIOException`. I inlined this one-liner to `HttpClientImpl::translateSendAsyncExecFailure`, and stopped using `Utils::toIOException`. I refrained from adapting `Utils::toIOException` since it is used by another component (i.e., push manager) and I did not want to introduce a behavioral change there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2460808920 From vyazici at openjdk.org Fri Oct 24 14:42:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 14:42:43 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v5] In-Reply-To: References: Message-ID: On Wed, 22 Oct 2025 11:35:04 GMT, Jaikiran Pai wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert `AbstractThrowingPublishers` changes > > src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java line 981: > >> 979: // Exceptions are often thrown from asynchronous code, making it >> 980: // difficult to trace back to the user's original entry point. >> 981: // Wrap exceptions explicitly to preserve that context. > > Nit - Would it better to reword this as: > >> // Exceptions are often thrown from asynchronous code, and the > // stacktrace may not always contain the application classes. > // That makes it difficult to trace back to the application code which > // invoked the HttpClient. Here we instantiate/recreate the > // exceptions to capture the application's calling code in the > // stacktrace of the thrown exception. Changed as suggested in 85501942a64. > test/jdk/java/net/httpclient/HttpClientSendAsyncExceptionTest.java line 72: > >> 70: var request = HttpRequest.newBuilder(URI.create("https://example.com")).GET().build(); >> 71: var responseBodyHandler = HttpResponse.BodyHandlers.discarding(); >> 72: client.sendAsync(request, responseBodyHandler).get(); > > Nit - it doesn't matter much in this code, but it's usually better to limit the code to the specific call that is expected to throw the expected exception type. That would mean moving out everything except the `Future.get()` call from the lambda. > > Same comment for the code in the other test methods too. Very true. Implemented in 3a7f0aa181c. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2460809351 PR Review Comment: https://git.openjdk.org/jdk/pull/27787#discussion_r2460809975 From myankelevich at openjdk.org Fri Oct 24 15:00:43 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 24 Oct 2025 15:00:43 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v3] In-Reply-To: References: Message-ID: > 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). Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27670/files - new: https://git.openjdk.org/jdk/pull/27670/files/d272f961..7dd7cc8c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=01-02 Stats: 20 lines in 1 file changed: 9 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27670/head:pull/27670 PR: https://git.openjdk.org/jdk/pull/27670 From michaelm at openjdk.org Fri Oct 24 15:29:26 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 24 Oct 2025 15:29:26 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v17] In-Reply-To: <9SX7PSIo4D9sZaH5IcHt2ASnEjhNQDKXvGwWFne93GE=.a0571f02-ae96-4bff-b591-90eef62e6205@github.com> References: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> <9SX7PSIo4D9sZaH5IcHt2ASnEjhNQDKXvGwWFne93GE=.a0571f02-ae96-4bff-b591-90eef62e6205@github.com> Message-ID: On Fri, 24 Oct 2025 06:16:59 GMT, Jaikiran Pai wrote: > Thank you for the update, this looks good to me. I'll let Michael (and Daniel) have a chance to review the updated version. > > On a general note, since you are contributing to the `HttpServer` area, I would also recommend that you run `tier2` tests locally. The GitHub actions job for the JDK only runs tier1 and that tier doesn't cover the networking area. I've started a tier1+2 test run, and will sponsor if it returns clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3443719711 From prappo at openjdk.org Fri Oct 24 17:03:30 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 24 Oct 2025 17:03:30 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 12:10:38 GMT, Volkan Yazici wrote: > Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. We might soon have saturating addition functionality in `java.time.Instant`; see: https://github.com/openjdk/jdk/pull/27549 I note that `jdk.internal.net.http.common.Deadline` also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the `minus` method in the codebase can be reimplemented alternatively. In which case `Deadline` could delete `minus`. Furthermore, if there's no need for saturating subtraction, do we need the `Deadline` class? What does it provide, that `Instant` does not? ------------- PR Review: https://git.openjdk.org/jdk/pull/27973#pullrequestreview-3377889088 From vyazici at openjdk.org Fri Oct 24 17:16:41 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 17:16:41 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v3] In-Reply-To: References: Message-ID: > 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: Invoke `preTerminationCallback` at `cancel()` too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27469/files - new: https://git.openjdk.org/jdk/pull/27469/files/bcd5bcc8..af496531 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=01-02 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 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 duke at openjdk.org Fri Oct 24 17:23:07 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 24 Oct 2025 17:23:07 GMT Subject: RFR: 7105350: HttpExchange's attributes are the same as HttpContext's attributes [v17] In-Reply-To: References: <7kf2cwf3oZm8TNOA85ZxW291MlHBaMQYEeCg3r9iwlU=.7aa1cc45-abb7-4700-acf1-4aa9845cf31c@github.com> <9SX7PSIo4D9sZaH5IcHt2ASnEjhNQDKXvGwWFne93GE=.a0571f02-ae96-4bff-b591-90eef62e6205@github.com> Message-ID: On Fri, 24 Oct 2025 15:27:00 GMT, Michael McMahon wrote: > On a general note, since you are contributing to the HttpServer area, I would also recommend that you run tier2 tests locally. The GitHub actions job for the JDK only runs tier1 and that tier doesn't cover the networking area. This explains a lot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27652#issuecomment-3444168342 From vyazici at openjdk.org Fri Oct 24 17:26:08 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 17:26:08 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v3] In-Reply-To: References: Message-ID: <36QxBBxPKX0S9ONFoysdlWlngTgbVktIHC-FYLrBkKQ=.8eb95c46-f32f-4810-911c-c5d09d725ef3@github.com> On Wed, 22 Oct 2025 12:20:41 GMT, Daniel Fuchs wrote: > Could we remove the `preTerminationCallback` parameter, and instead have the various subclass of `HttpBodySubscriberWrapper` supply `this.multi::cancelTimer()` to their super class? > > If I'm not mistaken all concrete subclasses of `HttpBodySubscriberWrapper` have access to the multi exchange. I had considered this approach, but had dropped it mainly because 1. `MultiExchange::cancelTimer` is a private method, and it would ideally remain so. The timer lifecycle, including cancellation, should be governed by `MultiExchange` itself, not by its subclasses. 2. The current flow makes it easy to trace where cancellation occurs by following method calls: `MultiExchange` ?`Exchange::readBodyAsync` ? `createResponseSubscriber`, etc. If we invert the logic, identifying where `cancelTimer` is invoked would become less transparent and would rely on IDE assistance. > That should reduce the amount of changes significantly. I can relate to that motivation. However, when adapting the code to let `HBSWrapper` subclasses call `cancelTimer`, the only files spared from modification would be `Exchange` and `ExchangeImpl`. So the overall reduction in changed lines would be minor. > Another possibility is to introduce a noarg protected abstract method in `HttpBodySubscriberWrapper` ... That approach would face the same downsides as letting subclasses directly call `MultiExchange::cancelTimer`. > It might need to be called on cancel as well? If not a comment explaining why might be good to have. If it's not called by cancel then maybe the method suggested above could be changed to `onCompletionNotified`. That was indeed an oversight ? fixed in 5621d911944. @dfuch, how would you prefer I proceed? Should I make `cancelTimer` public and pass it from `HBSWrapper` subclasses, or keep the current design? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2461364377 From vyazici at openjdk.org Fri Oct 24 17:42:01 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 17:42:01 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 12:10:38 GMT, Volkan Yazici wrote: > Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. > We might soon have saturating addition functionality in `java.time.Instant`; see: #27549 Great tip! ? I will hold this PR until #27549 gets merged, and use `Instant::plusSaturated` in `Deadline::plus*` and `::minus` methods. > I note that `jdk.internal.net.http.common.Deadline` also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the `minus` method in the codebase can be reimplemented alternatively. In which case `Deadline` could delete `minus`. I also have my reservations regarding the rich, yet seldom used API surface of `Deadline`. But revamping it is out of the scope of this work. > Furthermore, if there's no need for saturating subtraction, do we need the `Deadline` class? What does it provide, that `Instant` does not? In short, `Instant` is not necessarily generated using a monotonically-increasing `InstantSource`. `Deadline` is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See [this conversation for details](https://github.com/openjdk/jdk/pull/14450#pullrequestreview-1479500686). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27973#issuecomment-3444222646 From vyazici at openjdk.org Fri Oct 24 18:22:21 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 24 Oct 2025 18:22:21 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v4] In-Reply-To: References: Message-ID: > 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: Fix `HttpClient` doc typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27469/files - new: https://git.openjdk.org/jdk/pull/27469/files/af496531..3b5645eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 prappo at openjdk.org Fri Oct 24 18:40:03 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 24 Oct 2025 18:40:03 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 17:38:58 GMT, Volkan Yazici wrote: > > We might soon have saturating addition functionality in `java.time.Instant`; see: #27549 > > Great tip! ? I will hold this PR until #27549 gets merged, and use `Instant::plusSaturated` in `Deadline::plus*` and `::minus` methods. One problem for this PR is that the proposed `Instant` functionality in that PR will only work with `Duration` not `TemporalAmount`. Another problem is that you cannot implement saturating subtraction based on saturating addition here. If you are thinking along these lines, then it will fail if `amountToSubtract` is the minimum value for `Duration`: deadline.plus(amountToSubtract.negated()) Now, I understand that in your case you will never have negative duration, let alone such extremely negative one. But it would still be good to be robust, especially if it also involves less code. `Deadline.minus` seems to be used twice. Both times it is used for a comparison like this: t1 - dt < t0 To avoid subtraction, rearrange the terms. Different rearrangements enable different options, but either option is fine: * t1 - t0 < dt (compare durations using Instant.until/Duration.between) * t1 < t0 + dt (compare instants using future Instant.plusSaturating) > > I note that `jdk.internal.net.http.common.Deadline` also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the `minus` method in the codebase can be reimplemented alternatively. In which case `Deadline` could delete `minus`. > > I also have my reservations regarding the rich, yet seldom used API surface of `Deadline`. But revamping it is out of the scope of this work. > > > Furthermore, if there's no need for saturating subtraction, do we need the `Deadline` class? What does it provide, that `Instant` does not? > > In short, `Instant` is not necessarily generated using a monotonically-increasing `InstantSource`. `Deadline` is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See [this conversation for details](https://github.com/openjdk/jdk/pull/14450#pullrequestreview-1479500686). Okay, so you want your source of ticks to be exclusive and monotonic, neither of which could be guaranteed without introducing a few specialised types. Got it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27973#issuecomment-3444417312 From duke at openjdk.org Fri Oct 24 23:07:13 2025 From: duke at openjdk.org (Josiah Noel) Date: Fri, 24 Oct 2025 23:07:13 GMT Subject: Integrated: 7105350: HttpExchange's attributes are the same as HttpContext's attributes In-Reply-To: References: Message-ID: On Mon, 6 Oct 2025 16:09:40 GMT, Josiah Noel wrote: > Now ExchangeImpl will default to having a separate attribute map for the request duration. This pull request has now been integrated. Changeset: 35fdda08 Author: Josiah Noel <32279667+SentryMan at users.noreply.github.com> Committer: Michael McMahon URL: https://git.openjdk.org/jdk/commit/35fdda0889bd6a83027089672b643ef7ffc8a40c Stats: 50 lines in 3 files changed: 29 ins; 11 del; 10 mod 7105350: HttpExchange's attributes are the same as HttpContext's attributes Reviewed-by: michaelm, jpai, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/27652 From duke at openjdk.org Sat Oct 25 02:53:01 2025 From: duke at openjdk.org (Josiah Noel) Date: Sat, 25 Oct 2025 02:53:01 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v13] In-Reply-To: References: Message-ID: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Update ExchangeImpl.java - Merge remote-tracking branch 'upstream/master' into JDK-8368695 - reduce diff - Merge remote-tracking branch 'upstream/master' into JDK-8368695 - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - add exception test - Create UpgradeOutputStream.java - close raw streams - ... and 8 more: https://git.openjdk.org/jdk/compare/32697bf6...ae2b1184 ------------- Changes: https://git.openjdk.org/jdk/pull/27751/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=12 Stats: 25304 lines in 632 files changed: 6529 ins; 14641 del; 4134 mod Patch: https://git.openjdk.org/jdk/pull/27751.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751 PR: https://git.openjdk.org/jdk/pull/27751 From duke at openjdk.org Sat Oct 25 02:53:02 2025 From: duke at openjdk.org (Josiah Noel) Date: Sat, 25 Oct 2025 02:53:02 GMT Subject: Withdrawn: 8368695: Support 101 switching protocol in jdk.httpserver In-Reply-To: References: Message-ID: On Fri, 10 Oct 2025 19:45:57 GMT, Josiah Noel wrote: > - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request > - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed > - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream > - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27751 From ehs122100 at gmail.com Sat Oct 25 17:44:49 2025 From: ehs122100 at gmail.com (=?utf-8?B?7J2A7ZiE7IiY?=) Date: Sun, 26 Oct 2025 02:44:49 +0900 Subject: Missing HttpRequest variable in HttpClient javadoc synchronous example Message-ID: <769B8881-CD89-49E4-9104-9E76D21AFC58@gmail.com> Dear maintainers, I noticed a small issue in the HttpClient Javadoc that could confuse developers using the synchronous example. In HttpClient.java (lines 96?107), the synchronous example references an undefined request variable: HttpClient client = HttpClient.newBuilder() .version(Version.HTTP_1_1) .followRedirects(Redirect.NORMAL) .build(); HttpResponse response = client.send(request, BodyHandlers.ofString()); // ^^^^^ 'request' is not defined However, the asynchronous example immediately below (lines 111?119) correctly shows the HttpRequest creation: HttpRequest request = HttpRequest.newBuilder() .uri(URI.create("https://foo.com/")) .build(); This discrepancy would cause a compilation error if someone copies the synchronous example directly. I?d like to suggest adding the missing HttpRequest declaration to make the example complete and executable. Would this change be acceptable? Should I file a JBS issue for it? Thank you, Hyunsu Eun GitHub: ehs208 -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Sat Oct 25 18:05:38 2025 From: duke at openjdk.org (Josiah Noel) Date: Sat, 25 Oct 2025 18:05:38 GMT Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver Message-ID: <2XnDIC5P7NMXCNo4s84B6DZrKTwEQidxHJtKn9-ayHQ=.519512fd-7d54-428a-bc9b-2a64a153b037@github.com> Remaking the PR since I messed up the upstream merge on the other one. - adds a flag to ExchangeImpl to signal whether the current request is a GET Upgrade request - Adds a new `UpgradeInputStream`/`UpgradeOutputStream` to ensure that the server keeps track of when the upgraded request is closed - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream - on 101 response codes, `sendResponseHeaders` will use an `UpgradeInputStream` ------------- Commit messages: - Merge branch 'master' into JDK-8368695 - reduce diff - Merge remote-tracking branch 'upstream/master' into JDK-8368695 - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - Update SwitchingProtocolTest.java - add exception test - Create UpgradeOutputStream.java - close raw streams - tab - ... and 7 more: https://git.openjdk.org/jdk/compare/c3449de2...355732aa Changes: https://git.openjdk.org/jdk/pull/27989/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27989&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368695 Stats: 456 lines in 4 files changed: 449 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27989.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27989/head:pull/27989 PR: https://git.openjdk.org/jdk/pull/27989 From d.yamazaki at peya.tokyo Sun Oct 26 13:49:45 2025 From: d.yamazaki at peya.tokyo (Daisuke Yamazaki) Date: Sun, 26 Oct 2025 22:49:45 +0900 Subject: Proposal: 8355572: Implement Range header support for jwebserver In-Reply-To: <39bd5959-187f-449d-8e70-e3ea914d410d@oracle.com> References: <19a0ba8cd9b.3fb106283873448.4224658453221077600@peya.tokyo> <19a118bc8b8.2a6a9f384719417.6464960423018348784@peya.tokyo> <39bd5959-187f-449d-8e70-e3ea914d410d@oracle.com> Message-ID: <19a20c83e80.684178d05872896.197871077971555458@peya.tokyo> Hello, Thank you for your support and the helpful suggestions. I will explore possible implementation approaches for adding Range header support. If I can get it working successfully, I plan to submit a Pull Request for review. In the meantime, I will wait for any further feedbackon the proposal by anyone. Best regards, D. Yamazaki ---- On Fri, 24 Oct 2025 00:11:58 +0900 Daniel Fuchs wrote --- > Hi, > > I would support investigating adding support for Range header in > the FileServerHandler. > > In the HttpClient, we have recently added a new > BodyPublishers.ofFileChannel() request publisher as a > potential building block to ease implementation of > partial/resumable file uploads in applications. > > We have nothing out of the box for resumable file downloads > in the HttpClient API though. > > It would be good if you could use the HttpClient API > in the unit tests you will develop. Maybe we could use > that as an opportunity to learn whether some more building > blocks of general utility could be added on the client > side (in the future) to ease the implementation of applications > that would have a need for Range headers, such as to implement > a download manager for instance. > > best regards, > > -- daniel > > > On 23/10/2025 15:49, Daisuke Yamazaki wrote: > > Thank you for the clarification and context. > > > > I understand that there is a legitimate need for Range header support. > > However, whether such a feature is necessary for the simple jwebserver is > > still open for discussion. > > > > Nevertheless, while the benefits are clear, I do not see any significant > > drawbacks apart from potential maintainability or slight code growth. > > I personally think it would be reasonable to implement this feature. > > > > I plan to wait for a bit to allow further discussion, and if no objections > > arise, I intend to proceed with the implementation. > > > > ---- On Thu, 23 Oct 2025 02:56:29 +0900 Ethan McCue wrote --- > > > > > Adding for context that there are legitimate usages for this that are within the jdk httpserver's remit of jwebserver and educational purposes. Cheerpj would let a student run their java code in a browser and requires range headers support. > > > > > > On Wed, Oct 22, 2025, 7:23?AM Daisuke Yamazaki wrote: > > > > > > Hello all, > > > > > > I would like to work on implementing Range header support for jwebserver, > > > related to JDK-8355572. > > > Before I start working on it, i'd like to confirm whether it's okay for me to > > > take this issue. > > > > > > Here's my current design idea: > > > > > > 1. Introduce a RangeEntry record inside FileServerHandler to represent > > > each requested range > > > 2. In FileServerHandler.serveFile(), detect the Range header and parse it into > > > a list of RangeEntry objects. > > > If parsing fails or the range is invalid, return 416 Range Not Satisfiable. > > > 3. If multiple ranges are specified, generate a random boundary > > > string and return a multipart/byteranges response. > > > > > > Please let me know if it?s okay for me to proceed with this implementation, > > > or if there are any design points I should consider before starting. > > > > > > Thanks, > > > D. Yamazak > > > > > > > From josiahnoel at gmail.com Sun Oct 26 20:38:46 2025 From: josiahnoel at gmail.com (Josiah Noel) Date: Sun, 26 Oct 2025 16:38:46 -0400 Subject: HttpServer Create Convenience Method In-Reply-To: References: Message-ID: The InetSocketAddress may not be a huge burden, but if we can lift that burden that would be great. On Tue, Oct 14, 2025 at 4:58?PM Ethan McCue wrote: > I think the 0 at the end is worth tackling, it's not too much of a burden > to pass the InetSocketAddress > > On Tue, Oct 14, 2025 at 4:56?PM Josiah Noel wrote: > >> Long time no see, >> >> As you know, to create a server you need to do something like: HttpServer >> .create(new InetSocketAddress(8080), 0); >> >> Perchance would we be amenable to adding a convenience method to make it >> as easy as HttpServer.create(8080) >> >> -- >> Cheers, Josiah. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iklam at openjdk.org Mon Oct 27 06:27:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 27 Oct 2025 06:27:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Mon, 20 Oct 2025 17:40:20 GMT, Dan Heidinga wrote: >> These two accessors are currently not used in the AOT assembly phase. Maybe we can add an assert that the corresponding fields are null, and abort the AOT assembly otherwise? > > Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? > > Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null? > > The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem I looked at all the calls of the pattern `SharedSecrets.set.*::` java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream); These calls are all done inside a ``. In the four cases, only the first class (`java.io.ObjectInputFilter.Config`) has environment-dependent code inside its ``. Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new annotation `AOTUnsafeClassInitializer` (the opposite of the existing `AOTSafeClassInitializer`). If this class is initialized in the assembly phase, the VM will exit. I think we can leave the other 3 cases alone. An alternative is to rewrite the first case from: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); to SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() { ObjectInputFilter createFilter2(String pattern) { return Config.createFilter2(pattern); } }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2464550244 From pminborg at openjdk.org Mon Oct 27 08:52:04 2025 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 27 Oct 2025 08:52:04 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. src/hotspot/share/cds/cdsHeapVerifier.cpp line 186: > 184: if (fd->signature()->starts_with("Ljdk/internal/access/") && > 185: fd->signature()->ends_with("Access;")) { > 186: // The jdk/internal/access/*Access classes carry no states so they can be safely This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2464838946 From duke at openjdk.org Mon Oct 27 13:28:10 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 27 Oct 2025 13:28:10 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Mon, 27 Oct 2025 06:23:58 GMT, Ioi Lam wrote: >> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? >> >> Is there a way we can mark the fields in SharedSecrets as allowed to be assembly initialized vs those that must be null? >> >> The unfortunate thing is that if these fields didn't use Lambdas, they would also be fine to assembly-time initialize as it's the side-effect of the lambda forcing init that's the problem > > I looked at all the calls of the pattern `SharedSecrets.set.*::` > > > java/io/ObjectInputFilter.java: SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); > java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamAccess(ObjectInputStream::checkArray); > java/io/ObjectInputStream.java: SharedSecrets.setJavaObjectInputStreamReadString(ObjectInputStream::readString); > javax/crypto/SealedObject.java: SharedSecrets.setJavaxCryptoSealedObjectAccess(SealedObject::getExtObjectInputStream); > > > These calls are all done inside a ``. In the four cases, only the first class (`java.io.ObjectInputFilter.Config`) has environment-dependent code inside its ``. > > Maybe we should mark the `java.io.ObjectInputFilter.Config` class with a new annotation `AOTUnsafeClassInitializer` (the opposite of the existing `AOTSafeClassInitializer`). If this class is initialized in the assembly phase, the VM will exit. > > I think we can leave the other 3 cases alone. > > An alternative is to rewrite the first case from: > > > SharedSecrets.setJavaObjectInputFilterAccess(Config::createFilter2); > > > to > > > SharedSecrets.setJavaObjectInputFilterAccess(new JavaObjectInputFilterAccess() { > ObjectInputFilter createFilter2(String pattern) { > return Config.createFilter2(pattern); > } > }); The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`: SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() { public void checkArray(ObjectInputStream ois, Class arrayType, int arrayLength) throws ObjectStreamException { ois.checkArray(arrayType, arrayLength); } public String readString(ObjectInputStream ois) throws IOException { return ois.readString(); } }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2465667143 From prappo at openjdk.org Mon Oct 27 17:51:36 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Mon, 27 Oct 2025 17:51:36 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently Message-ID: Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/27972/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370568 Stats: 207 lines in 77 files changed: 0 ins; 0 del; 207 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From rriggs at openjdk.org Mon Oct 27 20:45:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 27 Oct 2025 20:45:02 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3385391439 From iklam at openjdk.org Tue Oct 28 04:06:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:06:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: Message-ID: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added StatelessOopsFinder ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27880/files - new: https://git.openjdk.org/jdk/pull/27880/files/a886aa85..c6ea93c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=00-01 Stats: 217 lines in 4 files changed: 211 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From iklam at openjdk.org Tue Oct 28 04:06:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:06:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: Message-ID: On Mon, 27 Oct 2025 08:48:40 GMT, Per Minborg wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added StatelessOopsFinder > > src/hotspot/share/cds/cdsHeapVerifier.cpp line 186: > >> 184: if (fd->signature()->starts_with("Ljdk/internal/access/") && >> 185: fd->signature()->ends_with("Access;")) { >> 186: // The jdk/internal/access/*Access classes carry no states so they can be safely > > This might be true for the time being, but adding such an assumption is a constraint for the future and should be documented. Perhaps we should have an interface `Access` that the various access classes implement, and where we could document this and other constraints of the access classes. I removed this hard-coded check and instead added `CDSHeapVerifier::add_shared_secret_accessors()`, which requires all AOT-initialized accessors to be stateless. I also added a negative test case for `SharedSecrets::javaObjectInputFilterAccess`, which is not stateless so it cannot be initialized in the AOT assembly phase. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467807545 From iklam at openjdk.org Tue Oct 28 04:06:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:06:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Mon, 27 Oct 2025 13:25:56 GMT, ExE Boss wrote: > The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess. I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467809826 From iklam at openjdk.org Tue Oct 28 04:10:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:10:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v2] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Tue, 28 Oct 2025 04:03:00 GMT, Ioi Lam wrote: >> The?`ObjectInputStreamReadString` interface should?just be?merged into?`ObjectInputStreamAccess`: >> >> SharedSecrets.setJavaObjectInputStreamAccess(new ObjectInputStreamAccess() { >> public void checkArray(ObjectInputStream ois, Class arrayType, int arrayLength) throws ObjectStreamException { >> ois.checkArray(arrayType, arrayLength); >> } >> >> public String readString(ObjectInputStream ois) throws IOException { >> return ois.readString(); >> } >> }); > >> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess. > > I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE? > Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2467814022 From iklam at openjdk.org Tue Oct 28 04:15:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 04:15:39 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v3] In-Reply-To: References: Message-ID: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8368199-add-aot-safe-class-initializer-annotation-to-shared-secrets - Added StatelessOopsFinder - 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27880/files - new: https://git.openjdk.org/jdk/pull/27880/files/c6ea93c3..6ae1172a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=01-02 Stats: 20837 lines in 485 files changed: 12666 ins; 4954 del; 3217 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From alanb at openjdk.org Tue Oct 28 07:00:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 07:00:03 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1044: > 1042: * already cancelled. This interrupts the threads executing unfinished subtasks. This > 1043: * method then waits for all threads to finish. If interrupted while waiting then it > 1044: * will continue to wait until the threads finish, before completing with the interrupted Can you drop the change to this file from the PR as we have reworded this paragraph as part of the updated for JEP 525. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468133283 From alanb at openjdk.org Tue Oct 28 07:52:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 07:52:03 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. I skimmed through the replace and it looks okay. There are several places where we should be linking as "interrupted status" will look like a grammatical error with the change. We do that as needed, not this PR. This is the first update to some of these files in 2025 so you will need to update the copyright header of those files. src/java.base/share/classes/java/net/DatagramSocket.java line 614: > 612: * interrupting a thread receiving a datagram packet will close the > 613: * underlying channel and cause this method to throw {@link > 614: * java.nio.channels.ClosedByInterruptException} with the interrupted Can you change this to "the thread's interrupted status set"? src/java.base/share/classes/java/net/DatagramSocket.java line 620: > 618: * datagram packet. In that case, interrupting the virtual thread will > 619: * cause it to wakeup and close the socket. This method will then throw > 620: * {@code SocketException} with the interrupted status set. Same thing here, and in ServerSocket and Socket. test/jdk/java/lang/Thread/virtual/CustomScheduler.java line 207: > 205: > 206: /** > 207: * Test running task with the carrier interrupted status set. We can change this to "the carrier's interrupted status set". ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387081610 PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468253205 PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468257078 PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468273763 From vyazici at openjdk.org Tue Oct 28 08:47:31 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 28 Oct 2025 08:47:31 GMT Subject: RFR: 8366575: Remove SDP support Message-ID: 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 ------------- Commit messages: - Remove SDP support Changes: https://git.openjdk.org/jdk/pull/28012/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28012&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366575 Stats: 732 lines in 13 files changed: 0 ins; 732 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28012.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28012/head:pull/28012 PR: https://git.openjdk.org/jdk/pull/28012 From alanb at openjdk.org Tue Oct 28 09:01:01 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 09:01:01 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 The tests for this feature were removed by "JEP 381: Remove the Solaris and SPARC Ports" and I don't think there are any other tests to purge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3455289444 From alanb at openjdk.org Tue Oct 28 09:39:30 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 09:39:30 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: <5U-sTIq_Pd8cXyzMvVU45J_zq1eogB0pn6X4iYKnUa0=.52739b0e-4981-4bce-b2ec-cd4a8adbf3ae@github.com> On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3387687382 From prappo at openjdk.org Tue Oct 28 10:06:36 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 28 Oct 2025 10:06:36 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v2] In-Reply-To: References: Message-ID: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision: - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d - Reword for clarity as suggested - Drop to ease upcoming merge from loom repo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27972/files - new: https://git.openjdk.org/jdk/pull/27972/files/a10f8b43..89dbafe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=00-01 Stats: 67 lines in 47 files changed: 4 ins; 0 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From alanb at openjdk.org Tue Oct 28 10:10:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 28 Oct 2025 10:10:11 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v2] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 10:06:36 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision: > > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d > + update test/... Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387827557 From jpai at openjdk.org Tue Oct 28 13:23:29 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 28 Oct 2025 13:23:29 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v9] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - merge latest from master branch - intialize headers - use MessageHeader.set() - merge latest from master branch - Daniel's review - comment to test code - merge latest from master branch - Daniel's review, use a class level field for URLConnection - Volkan's review - add a comment in test - merge latest from master branch - Daniel's suggestion - add reachability fence - Volkan's review - ... and 6 more: https://git.openjdk.org/jdk/compare/a3560020...9b8f74f3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27633/files - new: https://git.openjdk.org/jdk/pull/27633/files/05514212..9b8f74f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27633&range=07-08 Stats: 22368 lines in 551 files changed: 13248 ins; 5316 del; 3804 mod Patch: https://git.openjdk.org/jdk/pull/27633.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27633/head:pull/27633 PR: https://git.openjdk.org/jdk/pull/27633 From mdonovan at openjdk.org Tue Oct 28 13:45:36 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 28 Oct 2025 13:45:36 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan wrote: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. I'm still looking for a reviewer for this PR. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3456540544 From abarashev at openjdk.org Tue Oct 28 13:57:48 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 28 Oct 2025 13:57:48 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan wrote: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 100: > 98: getServerDname(), > 99: serverKeys.getPublic(), caKeys.getPublic(), > 100: CertificateBuilder.KeyUsage.DIGITAL_SIGNATURE, CertificateBuilder.KeyUsage.NONREPUDIATION, CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT) Line length > 80 here and below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469675945 From heidinga at openjdk.org Tue Oct 28 14:01:34 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 28 Oct 2025 14:01:34 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v3] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Tue, 28 Oct 2025 04:06:57 GMT, Ioi Lam wrote: >>> The ObjectInputStreamReadString interface should just be merged into ObjectInputStreamAccess. >> >> I agree. This seems better than using two separate Access interfaces with two separate lambdas. Maybe this should be done in a separate RFE? > >> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? > > @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors. Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2469685015 From abarashev at openjdk.org Tue Oct 28 14:04:19 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 28 Oct 2025 14:04:19 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan wrote: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. What about `javax/management/security/SecurityTest.java` unit test mentioned in the ticket? test/jdk/javax/management/security/keystoreAgent line 1: > 1: 0? Why do we need this and other binary key stores if we generate certificates on the fly? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3456634618 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469688660 From dfuchs at openjdk.org Tue Oct 28 14:20:27 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 28 Oct 2025 14:20:27 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v9] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 13:23:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - merge latest from master branch > - intialize headers - use MessageHeader.set() > - merge latest from master branch > - Daniel's review - comment to test code > - merge latest from master branch > - Daniel's review, use a class level field for URLConnection > - Volkan's review - add a comment in test > - merge latest from master branch > - Daniel's suggestion - add reachability fence > - Volkan's review > - ... and 6 more: https://git.openjdk.org/jdk/compare/060342d6...9b8f74f3 LGTM! Thanks @jaikiran . ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27633#pullrequestreview-3389033792 From prappo at openjdk.org Tue Oct 28 14:25:06 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Tue, 28 Oct 2025 14:25:06 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'jdk/master' into 8370568 - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d - Reword for clarity as suggested - Drop to ease upcoming merge from loom repo - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27972/files - new: https://git.openjdk.org/jdk/pull/27972/files/89dbafe0..b3297337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=01-02 Stats: 3639 lines in 160 files changed: 1891 ins; 1140 del; 608 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From abarashev at openjdk.org Tue Oct 28 14:34:34 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 28 Oct 2025 14:34:34 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures In-Reply-To: References: Message-ID: On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan wrote: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42: > 40: > 41: /* > 42: * @test id=tls13 What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469814283 From duke at openjdk.org Tue Oct 28 14:41:17 2025 From: duke at openjdk.org (Peyang) Date: Tue, 28 Oct 2025 14:41:17 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server Message-ID: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@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 ------------- Commit messages: - Fix HTTP Range header handling by validating end range and updating test cases - Fix ETag generation by removing weak validator prefix - Implement ETag and If-Range support - Change the content of the test file due to easier understanding - Adding test for ETag and If-Range header support - 8355572: Implement HTTP Range header support in FileServerHandler.serveFile() - Add tests for FileServerHandler - Add HTTP_RANGE_NOT_SATISFIABLE(416) to HTTP response code constants Changes: https://git.openjdk.org/jdk/pull/28021/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355572 Stats: 353 lines in 3 files changed: 345 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021 PR: https://git.openjdk.org/jdk/pull/28021 From fandreuzzi at openjdk.org Tue Oct 28 16:21:27 2025 From: fandreuzzi at openjdk.org (Francesco Andreuzzi) Date: Tue, 28 Oct 2025 16:21:27 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server 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: On Tue, 28 Oct 2025 14:32:43 GMT, Peyang 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 src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 316: > 314: } > 315: > 316: private String createETag( Path path) throws IOException { Suggestion: private String createETag(Path path) throws IOException { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2470213125 From duke at openjdk.org Tue Oct 28 16:31:06 2025 From: duke at openjdk.org (Peyang) Date: Tue, 28 Oct 2025 16:31:06 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2] 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: > 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: Remove extra spaces around Path parameter Co-authored-by: Francesco Andreuzzi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28021/files - new: https://git.openjdk.org/jdk/pull/28021/files/ea80255d..6a9e13f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=00-01 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 davidalayachew at gmail.com Fri Oct 24 14:56:00 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 24 Oct 2025 10:56:00 -0400 Subject: HttpServer should implement AutoCloseable? In-Reply-To: References: <2f77eeca-a9f8-4cf9-9569-0f4076b79d4f@oracle.com> Message-ID: Hello @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 wrote: > Thanks Alan, I'll reattempt this thread over there. > > On Fri, Oct 24, 2025 at 1:57?AM Alan Bateman > wrote: > >> On 23/10/2025 23:09, David Alayachew wrote: >> >> Hello @core-libs-dev , >> >> 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: From mdonovan at openjdk.org Tue Oct 28 17:43:12 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 28 Oct 2025 17:43:12 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v2] In-Reply-To: References: Message-ID: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - fixed indents and copyright year - Merge branch 'master' into update-md5-certs - 8353738: Update TLS unit tests to not use certificates with MD5 signatures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27342/files - new: https://git.openjdk.org/jdk/pull/27342/files/affe0fc9..a1933313 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=00-01 Stats: 213159 lines in 2786 files changed: 164071 ins; 31722 del; 17366 mod Patch: https://git.openjdk.org/jdk/pull/27342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342 PR: https://git.openjdk.org/jdk/pull/27342 From mdonovan at openjdk.org Tue Oct 28 17:43:16 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 28 Oct 2025 17:43:16 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v2] In-Reply-To: References: Message-ID: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com> On Tue, 28 Oct 2025 13:58:44 GMT, Artur Barashev wrote: >> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - fixed indents and copyright year >> - Merge branch 'master' into update-md5-certs >> - 8353738: Update TLS unit tests to not use certificates with MD5 signatures > > test/jdk/javax/management/security/keystoreAgent line 1: > >> 1: 0? > > Why do we need this and other binary key stores if we generate certificates on the fly? This is related to your question about SecurityTest.java. SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils. > test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42: > >> 40: >> 41: /* >> 42: * @test id=tls13 > > What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks? I think it helps with organization and troubleshooting tests. Without it, you have to read fairly dense logs to see which @run command failed. With separate @test blocks, it's more obvious. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470468093 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470461925 From duke at openjdk.org Tue Oct 28 17:53:31 2025 From: duke at openjdk.org (Florent Guillaume) Date: Tue, 28 Oct 2025 17:53:31 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Tue, 28 Oct 2025 16:31:06 GMT, Peyang 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: > > Remove extra spaces around Path parameter > > Co-authored-by: Francesco Andreuzzi src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 279: > 277: respHdrs.set("Last-Modified", getLastModified(path)); > 278: respHdrs.set("Accept-Ranges", "bytes"); > 279: respHdrs.set("ETag", createETag(path)); ETag is an entirely separate feature from Range and should be in its own separate followup Jira ticket and PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2470520913 From dfuchs at openjdk.org Tue Oct 28 18:38:34 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 28 Oct 2025 18:38:34 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Tue, 28 Oct 2025 17:49:29 GMT, Florent Guillaume wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra spaces around Path parameter >> >> Co-authored-by: Francesco Andreuzzi > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 279: > >> 277: respHdrs.set("Last-Modified", getLastModified(path)); >> 278: respHdrs.set("Accept-Ranges", "bytes"); >> 279: respHdrs.set("ETag", createETag(path)); > > ETag is an entirely separate feature from Range and should be in its own separate followup Jira ticket and PR. In addition should the Etag be considered weak as there is no way to guarantee that the file won't be modified between the time the attributes are read and the time the file content is read? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2470657515 From abarashev at openjdk.org Tue Oct 28 18:40:26 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Tue, 28 Oct 2025 18:40:26 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v2] In-Reply-To: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com> References: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com> Message-ID: On Tue, 28 Oct 2025 17:39:56 GMT, Matthew Donovan wrote: >> test/jdk/javax/management/security/keystoreAgent line 1: >> >>> 1: 0? >> >> Why do we need this and other binary key stores if we generate certificates on the fly? > > This is related to your question about SecurityTest.java. > > SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils. Oh, I see, it's a specific JMX test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470662409 From iklam at openjdk.org Tue Oct 28 18:51:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 18:51:40 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Updated comments about @AOTSafeClassInitializer in SharedSecrets.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27880/files - new: https://git.openjdk.org/jdk/pull/27880/files/6ae1172a..3121fd11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27880&range=02-03 Stats: 15 lines in 1 file changed: 12 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27880/head:pull/27880 PR: https://git.openjdk.org/jdk/pull/27880 From iklam at openjdk.org Tue Oct 28 18:51:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 28 Oct 2025 18:51:41 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: <9nT4KhL8RvkNXxmOkMdPAMpYTHEYYb1Durp2Hp0qJ9I=.43a4bb7a-f4b4-4367-9c6b-7329e2a92039@github.com> Message-ID: On Tue, 28 Oct 2025 13:57:46 GMT, Dan Heidinga wrote: >>> Is there a particular subset of the SharedSecrets accessors that we want to allow to be set during the assembly phase? >> >> @DanHeidinga , I updated the code to disallow any AOT-initialized accessors that are not stateless. See `CDSHeapVerifier::SharedSecretsAccessorFinder::do_field()`. This check should cover all existing use of Lambdas in setting the accessors, as well as future changes in the core lib that might add other types of states in the accessors. > > Can you update the comment on `SharedSecrets.java` to indicate that lambdas aren't safe to pre-initialize in this context? I updated the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27880#discussion_r2470693374 From heidinga at openjdk.org Tue Oct 28 18:57:01 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 28 Oct 2025 18:57:01 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments about @AOTSafeClassInitializer in SharedSecrets.java Marked as reviewed by heidinga (no project role). ------------- PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3390359439 From erikj at openjdk.org Tue Oct 28 19:20:22 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 28 Oct 2025 19:20:22 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3390435914 From lmesnik at openjdk.org Tue Oct 28 23:38:41 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 28 Oct 2025 23:38:41 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory Message-ID: There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. The tests that are incompatible with test thread factory are marked with test.thread.factory == null and the tests that are rather incompatible with virtual threads are makred with test.thread.factory != "Virtual" ------------- Commit messages: - 8370851: Mark hotspot and jdk tests incompatible with test thread factory Changes: https://git.openjdk.org/jdk/pull/28030/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370851 Stats: 32 lines in 14 files changed: 17 ins; 1 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/28030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030 PR: https://git.openjdk.org/jdk/pull/28030 From rriggs at openjdk.org Wed Oct 29 01:49:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 29 Oct 2025 01:49:05 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test... Nice cleanup. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3391422490 From abarashev at openjdk.org Wed Oct 29 02:00:06 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Wed, 29 Oct 2025 02:00:06 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v2] In-Reply-To: References: Message-ID: <_Uj-IKCUyXk183vz3D8_3dfUKA8NwrFxm5dRGbsgmfQ=.25bcae37-6622-4ce6-86f5-54abd430f312@github.com> On Tue, 28 Oct 2025 17:43:12 GMT, Matthew Donovan wrote: >> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. > > Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - fixed indents and copyright year > - Merge branch 'master' into update-md5-certs > - 8353738: Update TLS unit tests to not use certificates with MD5 signatures test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 222: > 220: "MD2, RSA keySize < 1024"); > 221: Security.setProperty("jdk.tls.disabledAlgorithms", > 222: "SSLv3, RC4, DH keySize < 768"); I think we should remove only `MD5`, here and in all other tests: // If MD5 is used in this test case, don't disable MD5 algorithm. SecurityUtils.removeFromDisabledTlsAlgs("MD5"); SecurityUtils.removeFromDisabledAlgs( "jdk.certpath.disabledAlgorithms", List.of("MD5")); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2471528938 From iklam at openjdk.org Wed Oct 29 02:53:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 02:53:09 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments about @AOTSafeClassInitializer in SharedSecrets.java Thanks everyone for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27880#issuecomment-3459415761 From liach at openjdk.org Wed Oct 29 03:23:04 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 29 Oct 2025 03:23:04 GMT Subject: RFR: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets [v4] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 18:51:40 GMT, Ioi Lam wrote: >> By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Updated comments about @AOTSafeClassInitializer in SharedSecrets.java The updated comments look very clear. Thanks! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27880#pullrequestreview-3391539750 From iklam at openjdk.org Wed Oct 29 03:26:16 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 29 Oct 2025 03:26:16 GMT Subject: Integrated: 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 22:20:12 GMT, Ioi Lam wrote: > By annotating `SharedSecrets` as `@AOTSafeClassInitializer`, we can avoid using the `@AOTRuntimeSetup` annotations in a few JDK core classes. This simplifies the implementation. It also brings us closer to the goal of making the AOT cache as a true snapshot of the JVM state that just needs to be resumed in the production run. This pull request has now been integrated. Changeset: 0687f120 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/0687f120cc324f35fe43d811b6beb4184fd854ec Stats: 260 lines in 10 files changed: 224 ins; 35 del; 1 mod 8368199: Add @AOTSafeClassInitializer to jdk.internal.access.SharedSecrets Reviewed-by: liach, heidinga ------------- PR: https://git.openjdk.org/jdk/pull/27880 From alanb at openjdk.org Wed Oct 29 07:00:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 29 Oct 2025 07:00:04 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28: > 26: * @bug 8284161 8303242 > 27: * @summary Test com.sun.management.ThreadMXBean with virtual threads > 28: * @requires test.thread.factory != "Virtual" This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2471923090 From prappo at openjdk.org Wed Oct 29 09:18:38 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 09:18:38 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 17:38:58 GMT, Volkan Yazici wrote: >> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. > >> We might soon have saturating addition functionality in `java.time.Instant`; see: #27549 > > Great tip! ? I will hold this PR until #27549 gets merged, and use `Instant::plusSaturated` in `Deadline::plus*` and `::minus` methods. > >> I note that `jdk.internal.net.http.common.Deadline` also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the `minus` method in the codebase can be reimplemented alternatively. In which case `Deadline` could delete `minus`. > > I also have my reservations regarding the rich, yet seldom used API surface of `Deadline`. But revamping it is out of the scope of this work. > >> Furthermore, if there's no need for saturating subtraction, do we need the `Deadline` class? What does it provide, that `Instant` does not? > > In short, `Instant` is not necessarily generated using a monotonically-increasing `InstantSource`. `Deadline` is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See [this conversation for details](https://github.com/openjdk/jdk/pull/14450#pullrequestreview-1479500686). @vy, `Instant.plusSaturating` is in the mainline: https://github.com/openjdk/jdk/commit/2758c6fda2f774d98ef0c24535a7f7e9fc722379 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27973#issuecomment-3460513225 From mbaesken at openjdk.org Wed Oct 29 09:29:08 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 29 Oct 2025 09:29:08 GMT Subject: RFR: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail Message-ID: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. ------------- Commit messages: - JDK-8368739 Changes: https://git.openjdk.org/jdk/pull/28041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8368739 Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28041/head:pull/28041 PR: https://git.openjdk.org/jdk/pull/28041 From jpai at openjdk.org Wed Oct 29 09:42:22 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 09:42:22 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test... Hello Pavel, these changes look OK to me. Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392430217 From jpai at openjdk.org Wed Oct 29 10:13:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 10:13:50 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Hello Volkan, I'm not familiar with this protocol, but the clean up itself looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3392545824 From jpai at openjdk.org Wed Oct 29 10:21:09 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 10:21:09 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v6] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 14:42:41 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > Volkan Yazici has updated the pull request incrementally with three additional commits since the last revision: > > - Avoid peeling off `UncheckedIOException` > - Minimize bodies passed to `assertThrows()` > - Improve `HttpClientImpl` comments The latest changes look good to me. For the change to the `test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java` test code, is that change still relevant/needed? I tried looking at that call sequence of that test but given all the layers/wrappers for these tests, I couldn't easily spot whether that change is necessary or not. Do you know what `throwable` instance gets passed to that `test(Throwable throwable)` method? Is it the "cause" from within an `ExecutionException`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27787#issuecomment-3460745863 From prappo at openjdk.org Wed Oct 29 10:25:59 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 10:25:59 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v4] In-Reply-To: References: Message-ID: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. Pavel Rappo 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: - Fix one more occurrence - Merge remote-tracking branch 'jdk/master' into 8370568 - Merge remote-tracking branch 'jdk/master' into 8370568 - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d - Reword for clarity as suggested - Drop to ease upcoming merge from loom repo - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27972/files - new: https://git.openjdk.org/jdk/pull/27972/files/b3297337..32e4c36a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=02-03 Stats: 2165 lines in 89 files changed: 1112 ins; 785 del; 268 mod Patch: https://git.openjdk.org/jdk/pull/27972.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972 PR: https://git.openjdk.org/jdk/pull/27972 From prappo at openjdk.org Wed Oct 29 10:26:00 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 10:26:00 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v3] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 09:39:55 GMT, Jaikiran Pai wrote: > Hello Pavel, these changes look OK to me. > > Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text. Moving from "interrupted" to "interrupt" was a slow drift rather than a landslide. I think it's okay to repair it once. _Loom_ is already in and once _structured concurrency_ is in, I don't expect many new occurrences of "interrupt" in the foreseeable future. But you are right, the important bit is the specification, not the code comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27972#issuecomment-3460767516 From jpai at openjdk.org Wed Oct 29 10:29:34 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 10:29:34 GMT Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status" consistently [v4] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 10:25:59 GMT, Pavel Rappo wrote: >> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. >> >> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. > > Pavel Rappo 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: > > - Fix one more occurrence > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Merge remote-tracking branch 'jdk/master' into 8370568 > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d > + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d > + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf > + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d > + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d > + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d > + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d > + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d > + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d > + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d > ... Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392609024 From duke at openjdk.org Wed Oct 29 10:57:32 2025 From: duke at openjdk.org (Peyang) Date: Wed, 29 Oct 2025 10:57:32 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Tue, 28 Oct 2025 18:36:01 GMT, Daniel Fuchs wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 279: >> >>> 277: respHdrs.set("Last-Modified", getLastModified(path)); >>> 278: respHdrs.set("Accept-Ranges", "bytes"); >>> 279: respHdrs.set("ETag", createETag(path)); >> >> ETag is an entirely separate feature from Range and should be in its own separate followup Jira ticket and PR. > > In addition should the Etag be considered weak as there is no way to guarantee that the file won't be modified between the time the attributes are read and the time the file content is read? Thank you for your reviews. I initially added `ETag` header for `If-Range` because I misunderstood it was a requirement, but it is actually not mandatory. So I will remove it from this patch. If a follow-up ticket could be created, since I don?t have permissions, I?d be happy to take it on. However, whether supporting ETag here is truly necessary is still open for discussion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2472542909 From jpai at openjdk.org Wed Oct 29 11:23:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 11:23:14 GMT Subject: RFR: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak [v9] In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 13:23:29 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? >> >> The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. >> >> `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. >> >> The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. >> >> One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. >> >> As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: >> >> >> Path regularFile = Path.of("hello.txt"); >> URLConnection conn = regularFile.toUri().toURL().openConnection(); >> // either of the following header related APIs >> long val = conn.getLastModified(); >> String val = conn.getHeaderField... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - merge latest from master branch > - intialize headers - use MessageHeader.set() > - merge latest from master branch > - Daniel's review - comment to test code > - merge latest from master branch > - Daniel's review, use a class level field for URLConnection > - Volkan's review - add a comment in test > - merge latest from master branch > - Daniel's suggestion - add reachability fence > - Volkan's review > - ... and 6 more: https://git.openjdk.org/jdk/compare/da28266b...9b8f74f3 Thank you all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27633#issuecomment-3460996312 From jpai at openjdk.org Wed Oct 29 11:23:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 11:23:16 GMT Subject: Integrated: 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak In-Reply-To: References: Message-ID: On Sat, 4 Oct 2025 16:23:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix a file descriptor leak in `sun.net.www.protocol.file.FileURLConnection`? > > The bug affects all JDK versions since Java 8 through mainline JDK. Furthermore, the issue isn't in any way related to "jar:" URLs or the JAR resources caching involved in the `JarURLConnection`. > > `sun.net.www.protocol.file.FileURLConnection` is a `java.net.URLConnection`. For this issue, the APIs on `URLConnection` that are of interest are `connect()`, header related APIs (the getHeaderXXXX(), getLastModified() and similar APIs) and `getInputStream()`. > > The existing implementation in `FileURLConnection` in its `connect()` implementation does readability checks on the underlying `File` instance. If the `File` is a directory then the readability check is done by verifying that a `File.list()` call does not return null. On the other hand, if the File is not a directory, then connect() constructs a temporary `java.io.FileInputStream` for the File and lets the FileInputStream's constructor implementation do the necessary readability checks. In either case, if the readability checks fail, then an IOException is thrown from this method and the FileURLConnection stays unconnected. > > One important detail of the implementation in `FileURLConnection.connect()` is that the `FileInputStream` that it creates for the regular-file readability check, it keeps it open when it returns from `connect()`. `connect()` itself doesn't return any value, so this `FileInputStream` that was created for readability check remains open without the application having access to it, unless the application calls `(File)URLConnection.getInputStream()`. The implementation of `FileURLConnection.getInputStream()` returns this previously constructed `InputStream` if `connect()` had previously suceeded with its readability checks. The application, as usual, is then expected to `close()` that `InputStream` that was returned from `URLConnection.getInputStream()`. This is the "normal" case, where the application at some point calls the `URLConnection.getInputStream()` and closes that stream. > > As noted previously, `URLConnection` has a few other APIs, for example the APIs that provide header values. An example: > > > Path regularFile = Path.of("hello.txt"); > URLConnection conn = regularFile.toUri().toURL().openConnection(); > // either of the following header related APIs > long val = conn.getLastModified(); > String val = conn.getHeaderField("foobar"); > // ... some other header... This pull request has now been integrated. Changeset: 4a0200ca Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/4a0200caf98ecb9bd1e6fe2670e79b36616a45fe Stats: 454 lines in 4 files changed: 417 ins; 11 del; 26 mod 8367561: Getting some "header" property from a file:// URL causes a file descriptor leak Reviewed-by: dfuchs, vyazici ------------- PR: https://git.openjdk.org/jdk/pull/27633 From vyazici at openjdk.org Wed Oct 29 11:37:19 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 11:37:19 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v7] In-Reply-To: References: Message-ID: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: Revert unnecessary changes to `AbstractThrowingSubscribers` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27787/files - new: https://git.openjdk.org/jdk/pull/27787/files/5621d911..6fad4020 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27787&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27787.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27787/head:pull/27787 PR: https://git.openjdk.org/jdk/pull/27787 From vyazici at openjdk.org Wed Oct 29 11:37:20 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 11:37:20 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v6] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 10:18:10 GMT, Jaikiran Pai wrote: > For the change to the `test/jdk/java/net/httpclient/AbstractThrowingSubscribers.java` test code, is that change still relevant/needed? @jaikiran, good catch! Removed in 6fad402094f. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27787#issuecomment-3461053946 From jpai at openjdk.org Wed Oct 29 11:52:23 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 11:52:23 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v7] In-Reply-To: References: Message-ID: <4BTSS4OwJ8D5fYHAIkBrdQ6anc80JMFjRIMzJS7PbS8=.99848851-ff25-4094-83a1-7faf6fb6fd9c@github.com> On Wed, 29 Oct 2025 11:37:19 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Revert unnecessary changes to `AbstractThrowingSubscribers` Thank you for the updates, this looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27787#pullrequestreview-3392924408 From mdonovan at openjdk.org Wed Oct 29 11:57:45 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 29 Oct 2025 11:57:45 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v3] In-Reply-To: References: Message-ID: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: changed tests to use SecurityUtils.removeDisabled*Algs methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27342/files - new: https://git.openjdk.org/jdk/pull/27342/files/a1933313..4804c90d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=01-02 Stats: 35 lines in 5 files changed: 10 ins; 8 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/27342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342 PR: https://git.openjdk.org/jdk/pull/27342 From duke at openjdk.org Wed Oct 29 12:21:40 2025 From: duke at openjdk.org (Peyang) Date: Wed, 29 Oct 2025 12:21:40 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] 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: <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@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: Remove ETag handling from response headers and related tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28021/files - new: https://git.openjdk.org/jdk/pull/28021/files/6a9e13f9..96486d34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=01-02 Stats: 81 lines in 2 files changed: 0 ins; 79 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021 PR: https://git.openjdk.org/jdk/pull/28021 From vyazici at openjdk.org Wed Oct 29 13:06:49 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 13:06:49 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 09:15:31 GMT, Pavel Rappo wrote: >>> We might soon have saturating addition functionality in `java.time.Instant`; see: #27549 >> >> Great tip! ? I will hold this PR until #27549 gets merged, and use `Instant::plusSaturated` in `Deadline::plus*` and `::minus` methods. >> >>> I note that `jdk.internal.net.http.common.Deadline` also wants to have saturating subtraction, and I wonder if that's really needed. It seems that the two usages of the `minus` method in the codebase can be reimplemented alternatively. In which case `Deadline` could delete `minus`. >> >> I also have my reservations regarding the rich, yet seldom used API surface of `Deadline`. But revamping it is out of the scope of this work. >> >>> Furthermore, if there's no need for saturating subtraction, do we need the `Deadline` class? What does it provide, that `Instant` does not? >> >> In short, `Instant` is not necessarily generated using a monotonically-increasing `InstantSource`. `Deadline` is introduced to avoid that ambiguity and guaranteed to be always monotonically-increasing. See [this conversation for details](https://github.com/openjdk/jdk/pull/14450#pullrequestreview-1479500686). > > @vy, `Instant.plusSaturating` is in the mainline: https://github.com/openjdk/jdk/commit/2758c6fda2f774d98ef0c24535a7f7e9fc722379 I discussed this matter internally with @pavelrappo and @dfuch, and decided to keep the code as is, and not use the recently introduced `Instant::plusSaturating(Duration)`, because: 1. This will result in extra work for backports. 2. Not all `Deadline` methods can take advantage of `Instant::plusSaturating`, e.g., `::between`, `::until`, and `::plus(long,TemporalUnit)`. Instead of some using `Instant::plusSaturating` and some catching `DateTimeException | ArithmeticException`, settle on a single approach to ease the cognitive load. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27973#issuecomment-3461414361 From mdoerr at openjdk.org Wed Oct 29 13:14:28 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 29 Oct 2025 13:14:28 GMT Subject: RFR: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail In-Reply-To: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> References: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> Message-ID: On Wed, 29 Oct 2025 09:22:02 GMT, Matthias Baesken wrote: > After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. > > The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. LGTM. Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28041#pullrequestreview-3393281289 From vyazici at openjdk.org Wed Oct 29 13:15:49 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 13:15:49 GMT Subject: RFR: 8368249: HttpClient: Translate exceptions thrown by sendAsync [v7] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 11:37:19 GMT, Volkan Yazici wrote: >> Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. >> >> `tier1-2` passes with the proposed changes. >> >> **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. >> >> [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 >> [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 > > Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: > > Revert unnecessary changes to `AbstractThrowingSubscribers` @dfuch, @jaikiran, thanks so much for the reviews. Tier1-2 is clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27787#issuecomment-3461442764 From vyazici at openjdk.org Wed Oct 29 13:15:51 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 13:15:51 GMT Subject: Integrated: 8368249: HttpClient: Translate exceptions thrown by sendAsync In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 07:21:21 GMT, Volkan Yazici wrote: > Ensure `HttpClient::sendAsync` translates every operational failure to an `IOException` as per specification. > > `tier1-2` passes with the proposed changes. > > **Context:** The parent issue, [JDK-8364733], reports that `HttpClient::sendAsync` leaks exceptions which do not extend from `IOException`, and this violates the method's specification. The [JDK-8367067] (#26876) sub-task improved issues around exceptions thrown by request body publishers ? which triggered the first encounter with this problem. This PR (and its associated sub-task) is aimed to end this saga. > > [JDK-8364733]: https://bugs.openjdk.org/browse/JDK-8364733 > [JDK-8367067]: https://bugs.openjdk.org/browse/JDK-8367067 This pull request has now been integrated. Changeset: 2c07214d Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/2c07214d7c075da5dd4a4e872aef29f58cef2bae Stats: 298 lines in 2 files changed: 298 ins; 0 del; 0 mod 8368249: HttpClient: Translate exceptions thrown by sendAsync Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/27787 From michaelm at openjdk.org Wed Oct 29 13:23:56 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 29 Oct 2025 13:23:56 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 Looks fine. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28012#pullrequestreview-3393336213 From vyazici at openjdk.org Wed Oct 29 14:27:43 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 14:27:43 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v5] In-Reply-To: References: Message-ID: > 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: Replace wrapper's `preTerminationCallback` argument with a method to be extended ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27469/files - new: https://git.openjdk.org/jdk/pull/27469/files/3b5645eb..e17131c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27469&range=03-04 Stats: 125 lines in 8 files changed: 32 ins; 44 del; 49 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 Wed Oct 29 14:31:58 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 14:31:58 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v5] In-Reply-To: References: Message-ID: <40ebCzGuX5E8b04bDTeqfz0dE7TzG1s5lgC_nXIwFP4=.8ae36eb6-62ad-4e69-a364-34910e35bbff@github.com> On Wed, 22 Oct 2025 12:20:41 GMT, Daniel Fuchs 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/MultiExchange.java line 414: > >> 412: return handleNoBody(r, exch); >> 413: } >> 414: return exch.readBodyAsync(responseHandler, this::cancelTimer) > > Could we remove the `preTerminationCallback` parameter, and instead have the various subclass of `HttpBodySubscriberWrapper` supply `this.multi::cancelTimer()` to their super class? > > If I'm not mistaken all concrete subclasses of `HttpBodySubscriberWrapper` have access to the multi exchange. > > That should reduce the amount of changes significantly. > > Another possibility is to introduce a noarg protected abstract method in `HttpBodySubscriberWrapper` and have all subclasses implement it. > We could call it for instance `protected abstract void onTerminationNotified();` and explain that it can be used to cancel a timer if needed. > > It might need to be called on cancel as well? > If not a comment explaining why might be good to have. If it's not called by cancel then maybe the method suggested above could be changed to `onCompletionNotified`. @dfuch, I've implemented the changes replacing `preTerminationCallback` argument with a `onTermination` method to be extended in `HttpBodySubscriberWrapper`. For your consideration: see [before] and [after]. [before]: https://github.com/openjdk/jdk/pull/27469/files/3b5645eb5ad79e3594767540c5fcb09b4242e3ab [after]: https://github.com/openjdk/jdk/pull/27469/files/e17131c042f6ab5292ca04eeb6f6be6d85fa784a ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2473460977 From jpai at openjdk.org Wed Oct 29 15:02:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 29 Oct 2025 15:02:50 GMT Subject: RFR: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail In-Reply-To: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> References: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> Message-ID: On Wed, 29 Oct 2025 09:22:02 GMT, Matthias Baesken wrote: > After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. > > The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. Hello Matthias, I was talking to Daniel @dfuch yesterday and we were thinking of reducing the system property value (like you have it here). I thought he meant we would reduce it for all platforms and that way we wouldn't have to duplicate these test definitions for AIX. It would be good to let Daniel have a look at this before integrating. You don't have to update the PR until you hear from Daniel. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28041#issuecomment-3462052476 From prappo at openjdk.org Wed Oct 29 15:39:31 2025 From: prappo at openjdk.org (Pavel Rappo) Date: Wed, 29 Oct 2025 15:39:31 GMT Subject: Integrated: 8370568: Refer to Thread.interrupted as "interrupted status" consistently In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo wrote: > Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent. > > Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes. This pull request has now been integrated. Changeset: 28f2591b Author: Pavel Rappo URL: https://git.openjdk.org/jdk/commit/28f2591bad49c4d1590325c3d315d850ab6bcc7d Stats: 260 lines in 77 files changed: 4 ins; 0 del; 256 mod 8370568: Refer to Thread.interrupted as "interrupted status" consistently Reviewed-by: jpai, rriggs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/27972 From dfuchs at openjdk.org Wed Oct 29 17:05:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 17:05:54 GMT Subject: RFR: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail In-Reply-To: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> References: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> Message-ID: <0orHf3AHF3ZLFU6C2JNDn8jWpdUp6ITkN3VvZzdkcVA=.011148ee-d4d9-4ea3-9539-2c97bd63b9fa@github.com> On Wed, 29 Oct 2025 09:22:02 GMT, Matthias Baesken wrote: > After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. > > The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. Hi Matthias - thanks for taking care of this one. This looks good. One alternative could have been to reduce the MTU to 8k uniformally, but what you are proposing is good. I am testing in our CI and will approve if I don't see any failure (and I don't expect this change would cause any). ------------- PR Review: https://git.openjdk.org/jdk/pull/28041#pullrequestreview-3394871360 From dfuchs at openjdk.org Wed Oct 29 17:26:26 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 17:26:26 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici 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 LGTM. The only other mention of sdp I could find in the sources and test is in [ct.properties](https://github.com/openjdk/jdk/blob/28f2591bad49c4d1590325c3d315d850ab6bcc7d/src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct.properties#L668) (javac) but since this file also contains references to corba packages that have long been removed I expect that reference should also remain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3462778460 From dfuchs at openjdk.org Wed Oct 29 17:43:40 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 17:43:40 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Wed, 29 Oct 2025 10:54:58 GMT, Peyang wrote: >> In addition should the Etag be considered weak as there is no way to guarantee that the file won't be modified between the time the attributes are read and the time the file content is read? > > Thank you for your reviews. > I initially added `ETag` header for `If-Range` because I misunderstood it was a requirement, but it is actually not mandatory. So I will remove it from this patch. > If a follow-up ticket could be created, since I don?t have permissions, I?d be happy to take it on. > However, whether supporting ETag here is truly necessary is still open for discussion. Do we also need/want to support `If-Range`? The thing is that we can't guarantee that the file will not be modified (either externally or by other threads in the same VM) after having read the last modified date. How strong is the guarantee provided by `If-Range` supposed to be? [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-last-modified) seems to imply that `Last-Modified` only provides a weak guarantee - as it is documented as "the date and time at which the origin server believes the selected representation was last modified". Does the same apply for `If-Range`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2474374557 From bpb at openjdk.org Wed Oct 29 17:44:40 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 29 Oct 2025 17:44:40 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v17] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - ... and 7 more: https://git.openjdk.org/jdk/compare/2f613911...2d4c4deb ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=16 Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From dfuchs at openjdk.org Wed Oct 29 18:15:34 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 18:15:34 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v3] In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 15:00:43 GMT, Mikhail Yankelevich 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). > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > comments Changes requested by dfuchs (Reviewer). test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 171: > 169: > 170: // Complete the exchange 10 second into the future. > 171: // Runs in parallel, so won't block the server stop Nit: when we reach here the server has already been stopped. So: 1. the comment is inaccurate. 2. we don't need the virtual thread or the exchangeDuration here. Just call countDown on the latch directly. 3. the first check `elapsed >= exchangeDuration.toNanos()` is not needed - since `exchangeDuration` is not needed. ------------- PR Review: https://git.openjdk.org/jdk/pull/27670#pullrequestreview-3395143925 PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2474500984 From daniel.fuchs at oracle.com Wed Oct 29 18:36:57 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 29 Oct 2025 18:36:57 +0000 Subject: Missing HttpRequest variable in HttpClient javadoc synchronous example In-Reply-To: <769B8881-CD89-49E4-9104-9E76D21AFC58@gmail.com> References: <769B8881-CD89-49E4-9104-9E76D21AFC58@gmail.com> Message-ID: Hi, Thank you for noticing this glitch. This is indeed something that should be fixed, and such a change would be welcomed. If you have a JBS account then please go on and file an issue. Otherwise you might do it through https://bugreport.java.com/bugreport/ best regards -- daniel On 25/10/2025 18:44, ??? wrote: > Dear maintainers, > > > I noticed a small issue in the HttpClient?Javadoc that could confuse > developers using the synchronous example. > > > In *HttpClient.java (lines 96?107)*, the synchronous example references > an undefined request?variable: > > |HttpClient client = HttpClient.newBuilder() .version(Version.HTTP_1_1) > .followRedirects(Redirect.NORMAL) .build(); HttpResponse > response = client.send(request, BodyHandlers.ofString()); // ^^^^^ > 'request' is not defined| > > However, the asynchronous example immediately below (*lines 111?119*) > correctly shows the HttpRequest?creation: > > |HttpRequest request = HttpRequest.newBuilder() > .uri(URI.create("https://foo.com/")) .build();| > > This discrepancy would cause a compilation error if someone copies the > synchronous example directly. > > I?d like to suggest adding the missing HttpRequest?declaration to make > the example complete and executable. > > > Would this change be acceptable? > > Should I file a JBS issue for it? > > > Thank you, > > *Hyunsu Eun*** > > GitHub: ehs208 > From dfuchs at openjdk.org Wed Oct 29 19:18:58 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 19:18:58 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Fri, 24 Oct 2025 12:10:38 GMT, Volkan Yazici wrote: > Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 73: > 71: ArithmeticException _) { // "long overflow" > 72: return nanosToAdd > 0 ? Deadline.MAX : Deadline.MIN; > 73: } We could add more fast-path checks here to take care of the special case where this is already `Deadline.MAX` or `Deadline.MIN`, but we expect that in most cases there will be no exception, so you have probably reached the sweet spot by just checking for 0. This could be revisited later on when we have value classes, and if Deadline and Instant are turned into value classes. src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 207: > 205: ArithmeticException _) { // "long overflow" > 206: return duration.isPositive() ? Deadline.MAX : Deadline.MIN; > 207: } This is the place where we could use the new method. As we probably will want to backport I think it's better to keep the proposed implementation for now. src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 233: > 231: public long until(Deadline endExclusive, TemporalUnit unit) { > 232: int delta = compareTo(endExclusive); > 233: if (delta == 0) return 0; I'd suggest moving these two lines into the catch clause. We only need the comparison when an exception is raised. I don't think the case where we would get 0 occurs very often, and it would be handled correctly (without throwing) by the regular path anyway. src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 321: > 319: } > 320: } > 321: Do we need to change this method? I would just revert them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2474834823 PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2474868867 PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2474899955 PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2475007515 From dfuchs at openjdk.org Wed Oct 29 19:27:28 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 29 Oct 2025 19:27:28 GMT Subject: RFR: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail In-Reply-To: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> References: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> Message-ID: On Wed, 29 Oct 2025 09:22:02 GMT, Matthias Baesken wrote: > After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. > > The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. Tests are green ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28041#pullrequestreview-3395719795 From vyazici at openjdk.org Wed Oct 29 20:44:01 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 20:44:01 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 19:16:03 GMT, Daniel Fuchs wrote: >> Introduce necessary fixes to address exceptions thrown when excessive `Duration`s are provided to `Duration`-accepting `HttpClient` public APIs. > > src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 321: > >> 319: } >> 320: } >> 321: > > Do we need to change this method? I would just revert them. `Duration#between(Temporal,Temporal)` can throw `DateTimeException` and `ArithmeticException`, but not in our case due to the reason I elaborated in the comment. In this change, I've removed these two exceptions from the Javadoc, since they cannot happen. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2475376403 From vyazici at openjdk.org Wed Oct 29 20:53:22 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 20:53:22 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values [v2] In-Reply-To: References: Message-ID: > 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: Move `delta == 0` in `until()` to the catch block ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27973/files - new: https://git.openjdk.org/jdk/pull/27973/files/c2179b8a..856aea73 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27973&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 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 Wed Oct 29 20:53:24 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 29 Oct 2025 20:53:24 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values [v2] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 19:03:19 GMT, Daniel Fuchs wrote: >> Volkan Yazici has updated the pull request incrementally with one additional commit since the last revision: >> >> Move `delta == 0` in `until()` to the catch block > > src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 233: > >> 231: public long until(Deadline endExclusive, TemporalUnit unit) { >> 232: int delta = compareTo(endExclusive); >> 233: if (delta == 0) return 0; > > I'd suggest moving these two lines into the catch clause. We only need the comparison when an exception is raised. I don't think the case where we would get 0 occurs very often, and it would be handled correctly (without throwing) by the regular path anyway. Implemented in 856aea735cf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2475406481 From sspitsyn at openjdk.org Thu Oct 30 00:06:00 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 30 Oct 2025 00:06:00 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" This looks good to me modulo the comment from Alan. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3396935258 From lmesnik at openjdk.org Thu Oct 30 03:12:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 03:12:46 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: reverted back one test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28030/files - new: https://git.openjdk.org/jdk/pull/28030/files/e132e73f..4eec9c78 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28030.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030 PR: https://git.openjdk.org/jdk/pull/28030 From lmesnik at openjdk.org Thu Oct 30 03:12:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 03:12:46 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 06:56:56 GMT, Alan Bateman wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> reverted back one test > > test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28: > >> 26: * @bug 8284161 8303242 >> 27: * @summary Test com.sun.management.ThreadMXBean with virtual threads >> 28: * @requires test.thread.factory != "Virtual" > > This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs? > > (all the rest looks okay, excluded via ProblemList-Virtual in the loom repo) Yes, it is not failing. I thought to exclude it because it is virtual thread specific. But I agree, it is not complaint with overall approach. I am reverting this test change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2476276800 From alanb at openjdk.org Thu Oct 30 06:54:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Oct 2025 06:54:10 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik wrote: >> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. >> >> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. >> >> The tests that are incompatible with test thread factory are marked with >> test.thread.factory == null >> and the tests that are rather incompatible with virtual threads are makred >> with >> test.thread.factory != "Virtual" > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > reverted back one test Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3397682870 From mbaesken at openjdk.org Thu Oct 30 08:09:18 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 30 Oct 2025 08:09:18 GMT Subject: RFR: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail In-Reply-To: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> References: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> Message-ID: On Wed, 29 Oct 2025 09:22:02 GMT, Matthias Baesken wrote: > After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. > > The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28041#issuecomment-3466550132 From mbaesken at openjdk.org Thu Oct 30 08:09:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 30 Oct 2025 08:09:19 GMT Subject: Integrated: 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail In-Reply-To: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> References: <4TKPMRITWgnUQGOCJYAwoZvdif0KfYkVjusYS1xN5j8=.ec39beac-4a6b-47da-977c-51507993d293@github.com> Message-ID: On Wed, 29 Oct 2025 09:22:02 GMT, Matthias Baesken wrote: > After [JDK-8349910](https://bugs.openjdk.org/browse/JDK-8349910) the 2 tests java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail on AIX; all the other HTTP3 related tests seem to do fine on AIX. > > The tests fail in the runs with `-Djdk.httpclient.quic.defaultMTU=16336` . This setting has to be adjusted to a lower value for AIX to work. This pull request has now been integrated. Changeset: 5096dc89 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/5096dc8972f7e2885ba4b1d994be630c7fc3b3a6 Stats: 51 lines in 1 file changed: 51 ins; 0 del; 0 mod 8368739: [AIX] java/net/httpclient/http3/H3SimpleGet.java#useNioSelector and #with-continuations fail Reviewed-by: mdoerr, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/28041 From duke at openjdk.org Thu Oct 30 10:25:35 2025 From: duke at openjdk.org (Peyang) Date: Thu, 30 Oct 2025 10:25:35 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v2] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: <7LxsJ91RRcInEaOageLbbnjJtGXG6oY5BuLmPeXOfYg=.f37debda-d132-45dc-b7fd-c422e0992ad3@github.com> On Wed, 29 Oct 2025 17:40:44 GMT, Daniel Fuchs wrote: >> Thank you for your reviews. >> I initially added `ETag` header for `If-Range` because I misunderstood it was a requirement, but it is actually not mandatory. So I will remove it from this patch. >> If a follow-up ticket could be created, since I don?t have permissions, I?d be happy to take it on. >> However, whether supporting ETag here is truly necessary is still open for discussion. > > Do we also need/want to support `If-Range`? The thing is that we can't guarantee that the file will not be modified (either externally or by other threads in the same VM) after having read the last modified date. How strong is the guarantee provided by `If-Range` supposed to be? > > [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#name-last-modified) seems to imply that `Last-Modified` only provides a weak guarantee - as it is documented as "the date and time at which the origin server believes the selected representation was last modified". > > Does the same apply for `If-Range`? You are right that we cannot guarantee that the file won?t be modified after reading its attributes. RFC 9110 defines `Last-Modified` as "the date and time at which the origin server believes the selected representation was last modified", so it only provides a weak guarantee. Strict `If-Range` support would require a strong `ETag`. Since we don?t have strong `ETag` support yet, we only provide a weak `Last-Modified`-based check, which is usually sufficient for resuming downloads. Full `If-Range` support can be considered later if needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477360821 From dfuchs at openjdk.org Thu Oct 30 10:45:42 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 10:45:42 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values [v2] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 20:53:22 GMT, Volkan Yazici 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: > > Move `delta == 0` in `until()` to the catch block Changes requested by dfuchs (Reviewer). src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 318: > 316: // Hence, we should never receive a numeric overflow while calculating the delta between two deadlines. > 317: throw new IllegalStateException("Unexpected overflow", exception); > 318: } hmmm... `DateTimeException` and `ArithmeticException` are both `RuntimeException`. We know they won't be thrown here, so there's no point in trying to catch them to replace them with another exception, since that would essentially be dead code. Removing the `@throws` from the API doc is the right call though. If you want you can add an `@apiNote` to say this method will never throw `DateTimeException` or `ArithmeticException` since duration between two deadlines will never overflow; but this is an internal API so the comment in the code below is probably enough. Suggestion: if (startInclusive.equals(endExclusive)) return Duration.ZERO; // `Deadline` works with `Instant` under the hood. // Delta between `Instant.MIN` and `Instant.MAX` fits in a `Duration`. // Hence, we should never receive a numeric overflow while calculating the delta between two deadlines. return Duration.between(startInclusive.deadline, endExclusive.deadline); ------------- PR Review: https://git.openjdk.org/jdk/pull/27973#pullrequestreview-3398689313 PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2477461476 From dfuchs at openjdk.org Thu Oct 30 10:45:45 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 10:45:45 GMT Subject: RFR: 8368528: HttpClient.Builder.connectTimeout should accept arbitrarily large values [v2] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 20:40:59 GMT, Volkan Yazici wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/common/Deadline.java line 321: >> >>> 319: } >>> 320: } >>> 321: >> >> Do we need to change this method? I would just revert them. > > `Duration#between(Temporal,Temporal)` can throw `DateTimeException` and `ArithmeticException`, but not in our case due to the reason I elaborated in the comment. In this change, I've removed these two exceptions from the Javadoc, since they cannot happen. Oh - yes we don't take Temporal but Deadline as paramater which eliminates the possibility of overflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27973#discussion_r2477384162 From dfuchs at openjdk.org Thu Oct 30 11:22:31 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 11:22:31 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> Message-ID: <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> On Wed, 29 Oct 2025 12:21:40 GMT, Peyang 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: > > Remove ETag handling from response headers and related tests src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 315: > 313: } > 314: > 315: private List parseRangeHeader(String rangeHeader, long fileSize) { It would be good to add a comment block before this method (no need for javadoc-style, // is enough) to give an example of all the valid values for the `rangeHeader` string. That would help in asserting that the method body does what it is supposed to do, and it will make easier to maintain should a bug be discovered later on. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477643304 From kevinw at openjdk.org Thu Oct 30 11:43:29 2025 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 30 Oct 2025 11:43:29 GMT Subject: RFR: 8370851: Mark hotspot and jdk tests incompatible with test thread factory [v2] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik wrote: >> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. >> >> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. >> >> The tests that are incompatible with test thread factory are marked with >> test.thread.factory == null >> and the tests that are rather incompatible with virtual threads are makred >> with >> test.thread.factory != "Virtual" > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > reverted back one test Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3399147490 From duke at openjdk.org Thu Oct 30 11:45:35 2025 From: duke at openjdk.org (Florent Guillaume) Date: Thu, 30 Oct 2025 11:45:35 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> Message-ID: On Thu, 30 Oct 2025 11:19:59 GMT, Daniel Fuchs wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove ETag handling from response headers and related tests > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 315: > >> 313: } >> 314: >> 315: private List parseRangeHeader(String rangeHeader, long fileSize) { > > It would be good to add a comment block before this method (no need for javadoc-style, // is enough) to give an example of all the valid values for the `rangeHeader` string. That would help in asserting that the method body does what it is supposed to do, and it will make easier to maintain should a bug be discovered later on. Not a reviewer, but I'd go further: this kind of method should be directly unit tested (not indirectly through all the http layers), and full coverage ensured. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477765798 From dfuchs at openjdk.org Thu Oct 30 12:01:38 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 12:01:38 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> Message-ID: On Wed, 29 Oct 2025 12:21:40 GMT, Peyang 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: > > Remove ETag handling from response headers and related tests I haven't finished reviewing but here are some early feedback. Also support for Range header will need to be documented in `SimpleFileServer.java`. See https://docs.oracle.com/en/java/javase/25/docs/api/jdk.httpserver/com/sun/net/httpserver/SimpleFileServer.html#file-handler-heading src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 369: > 367: RangeEntry range = ranges.get(0); > 368: respHdrs.set("Content-Range", > 369: "bytes %d-%d/%d".formatted(range.start, range.end, fileSize)); You should use %s rather than %d here because %d is localized. src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 382: > 380: os.write(("--" + boundary + "\r\n").getBytes(UTF_8)); > 381: os.write(("Content-Type: " + fileContentType + "\r\n").getBytes(UTF_8)); > 382: os.write("Content-Range: bytes %d-%d/%d\r\n\r\n" same here - use %s ------------- Changes requested by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28021#pullrequestreview-3399231155 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477820971 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477824494 From duke at openjdk.org Thu Oct 30 12:42:06 2025 From: duke at openjdk.org (Peyang) Date: Thu, 30 Oct 2025 12:42:06 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> Message-ID: <0RSmJXUX_aWGO203ASziNebygsB-wJLquwf4XpVleOk=.19e3e579-4baa-4177-93e1-7074ef47620c@github.com> On Thu, 30 Oct 2025 11:42:38 GMT, Florent Guillaume wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 315: >> >>> 313: } >>> 314: >>> 315: private List parseRangeHeader(String rangeHeader, long fileSize) { >> >> It would be good to add a comment block before this method (no need for javadoc-style, // is enough) to give an example of all the valid values for the `rangeHeader` string. That would help in asserting that the method body does what it is supposed to do, and it will make easier to maintain should a bug be discovered later on. > > Not a reviewer, but I'd go further: this kind of method should be directly unit tested (not indirectly through all the http layers), and full coverage ensured. Thanks for your reviews. Regarding adding comments to the method, I will make the corresponding changes. As for the unit tests, it is indeed more reasonable to test this method directly rather than through the HTTP layer. With that in mind, would it be okay to make this method package-private so that it can be called from the test code and properly unit tested? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2477942761 From dfuchs at openjdk.org Thu Oct 30 13:39:24 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 13:39:24 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: <0RSmJXUX_aWGO203ASziNebygsB-wJLquwf4XpVleOk=.19e3e579-4baa-4177-93e1-7074ef47620c@github.com> References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> <0RSmJXUX_aWGO203ASziNebygsB-wJLquwf4XpVleOk=.19e3e579-4baa-4177-93e1-7074ef47620c@github.com> Message-ID: On Thu, 30 Oct 2025 12:39:09 GMT, Peyang wrote: >> Not a reviewer, but I'd go further: this kind of method should be directly unit tested (not indirectly through all the http layers), and full coverage ensured. > > Thanks for your reviews. > Regarding adding comments to the method, I will make the corresponding changes. > As for the unit tests, it is indeed more reasonable to test this method directly rather than through the HTTP layer. > With that in mind, would it be okay to make this method package-private so that it can be called from the test code and properly unit tested? Yes that would be OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2478141352 From duke at openjdk.org Thu Oct 30 14:03:49 2025 From: duke at openjdk.org (Peyang) Date: Thu, 30 Oct 2025 14:03:49 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> <0RSmJXUX_aWGO203ASziNebygsB-wJLquwf4XpVleOk=.19e3e579-4baa-4177-93e1-7074ef47620c@github.com> Message-ID: On Thu, 30 Oct 2025 13:36:42 GMT, Daniel Fuchs wrote: >> Thanks for your reviews. >> Regarding adding comments to the method, I will make the corresponding changes. >> As for the unit tests, it is indeed more reasonable to test this method directly rather than through the HTTP layer. >> With that in mind, would it be okay to make this method package-private so that it can be called from the test code and properly unit tested? > > Yes that would be OK. I plan to make this method `public static` so that it can be tested directly. This method doesn?t depend on the handler instance, and doing so will allow the test class which currently has no package declaration to invoke it. Please let me know if you have any concerns. Also, sorry for the long messages: this is my first contribution and I?m trying to be thorough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2478238717 From dfuchs at openjdk.org Thu Oct 30 14:47:56 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 14:47:56 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v5] In-Reply-To: <40ebCzGuX5E8b04bDTeqfz0dE7TzG1s5lgC_nXIwFP4=.8ae36eb6-62ad-4e69-a364-34910e35bbff@github.com> References: <40ebCzGuX5E8b04bDTeqfz0dE7TzG1s5lgC_nXIwFP4=.8ae36eb6-62ad-4e69-a364-34910e35bbff@github.com> Message-ID: On Wed, 29 Oct 2025 14:29:30 GMT, Volkan Yazici wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/MultiExchange.java line 414: >> >>> 412: return handleNoBody(r, exch); >>> 413: } >>> 414: return exch.readBodyAsync(responseHandler, this::cancelTimer) >> >> Could we remove the `preTerminationCallback` parameter, and instead have the various subclass of `HttpBodySubscriberWrapper` supply `this.multi::cancelTimer()` to their super class? >> >> If I'm not mistaken all concrete subclasses of `HttpBodySubscriberWrapper` have access to the multi exchange. >> >> That should reduce the amount of changes significantly. >> >> Another possibility is to introduce a noarg protected abstract method in `HttpBodySubscriberWrapper` and have all subclasses implement it. >> We could call it for instance `protected abstract void onTerminationNotified();` and explain that it can be used to cancel a timer if needed. >> >> It might need to be called on cancel as well? >> If not a comment explaining why might be good to have. If it's not called by cancel then maybe the method suggested above could be changed to `onCompletionNotified`. > > @dfuch, I've implemented the changes replacing `preTerminationCallback` argument with a `onTermination` method to be extended in `HttpBodySubscriberWrapper`. For your consideration: see [before] and [after]. > > [before]: https://github.com/openjdk/jdk/pull/27469/files/3b5645eb5ad79e3594767540c5fcb09b4242e3ab > [after]: https://github.com/openjdk/jdk/pull/27469/files/e17131c042f6ab5292ca04eeb6f6be6d85fa784a Thanks for that @vy . I find the [after](https://github.com/openjdk/jdk/pull/27469/files/e17131c042f6ab5292ca04eeb6f6be6d85fa784a) much cleaner. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2478395981 From dfuchs at openjdk.org Thu Oct 30 14:48:00 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 14:48:00 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v5] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 14:27:43 GMT, Volkan Yazici 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: > > 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(). 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2478386175 PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2478212917 From dfuchs at openjdk.org Thu Oct 30 14:55:28 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 30 Oct 2025 14:55:28 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> <7bv-lMNplYSkj9uWs6xrgHOZ038InVwch1AwdjFUHbA=.d23abb9e-26d4-4a4f-9be0-c06606a98197@github.com> <0RSmJXUX_aWGO203ASziNebygsB-wJLquwf4XpVleOk=.19e3e579-4baa-4177-93e1-7074ef47620c@github.com> Message-ID: On Thu, 30 Oct 2025 14:00:56 GMT, Peyang wrote: >> Yes that would be OK. > > I plan to make this method `public static` so that it can be tested directly. > This method doesn?t depend on the handler instance, and doing so will allow the test class which currently has no package declaration to invoke it. > Please let me know if you have any concerns. > > Also, sorry for the long messages: this is my first contribution and I?m trying to be thorough. Public static sounds fine to me. No need for apologies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2478427036 From lmesnik at openjdk.org Thu Oct 30 15:38:19 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 30 Oct 2025 15:38:19 GMT Subject: Integrated: 8370851: Mark hotspot and jdk tests incompatible with test thread factory In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik wrote: > There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag. > > Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads. > > The tests that are incompatible with test thread factory are marked with > test.thread.factory == null > and the tests that are rather incompatible with virtual threads are makred > with > test.thread.factory != "Virtual" This pull request has now been integrated. Changeset: ed36b9bb Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/ed36b9bb6f3d429db6accfb3b096e50e7f2217ff Stats: 29 lines in 13 files changed: 15 ins; 1 del; 13 mod 8370851: Mark hotspot and jdk tests incompatible with test thread factory Reviewed-by: alanb, kevinw, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28030 From duke at openjdk.org Thu Oct 30 15:53:19 2025 From: duke at openjdk.org (Peyang) Date: Thu, 30 Oct 2025 15:53:19 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v4] 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: > 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 four additional commits since the last revision: - Enhance HTTP Range header support by making parseRangeHeader() public and adding comprehensive tests for valid and invalid range headers - Remove redundant import statements - Add quick explanation of parseRangeHeader() method - Fix number formatting to use string interpolation instead of %d to avoid locale issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28021/files - new: https://git.openjdk.org/jdk/pull/28021/files/96486d34..0b979c74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=02-03 Stats: 93 lines in 4 files changed: 86 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28021/head:pull/28021 PR: https://git.openjdk.org/jdk/pull/28021 From duke at openjdk.org Thu Oct 30 15:58:11 2025 From: duke at openjdk.org (Peyang) Date: Thu, 30 Oct 2025 15:58:11 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v5] 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: <-EmbxqrSmF51o9BalzRq-lbodfbzm0yHAkLkmcPY0YM=.2f68ecd6-91d8-4115-ad3f-5fd311c1568d@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: Convert line endings in TEST.properties from CRLF to LF ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28021/files - new: https://git.openjdk.org/jdk/pull/28021/files/0b979c74..1a98e29f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 1 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 Thu Oct 30 16:20:22 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 30 Oct 2025 16:20:22 GMT Subject: RFR: 8208693: HttpClient: Extend the request timeout's scope to cover the response body [v5] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 14:27:43 GMT, Volkan Yazici 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: > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27469#discussion_r2478722554 From abarashev at openjdk.org Thu Oct 30 21:59:07 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 30 Oct 2025 21:59:07 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v3] In-Reply-To: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> References: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> Message-ID: On Wed, 29 Oct 2025 11:57:45 GMT, Matthew Donovan wrote: >> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > changed tests to use SecurityUtils.removeDisabled*Algs methods test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221: > 219: if (args[1].contains("MD5")) { > 220: // MD5 is used in this test case, don't disable MD5 algorithm. > 221: SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms", Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2479623980 From abarashev at openjdk.org Thu Oct 30 22:05:04 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Thu, 30 Oct 2025 22:05:04 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v3] In-Reply-To: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> References: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> Message-ID: On Wed, 29 Oct 2025 11:57:45 GMT, Matthew Donovan wrote: >> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > changed tests to use SecurityUtils.removeDisabled*Algs methods test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 184: > 182: SSLContext ctx = SSLContext.getInstance(protocol); > 183: > 184: if (keyCert != null) { Why do we check for keyCert being `null`? Do we expect some future tests to make use of it? BTW, in such case `CertificateBuilder.printCertificate` would fail first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2479633177 From duke at openjdk.org Fri Oct 31 10:12:27 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 10:12:27 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] 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: > 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: Add documentation for HTTP range requests support in SimpleFileServer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28021/files - new: https://git.openjdk.org/jdk/pull/28021/files/1a98e29f..1ed7f76f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=04-05 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 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 Fri Oct 31 10:23:04 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 10:23:04 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> Message-ID: On Thu, 30 Oct 2025 11:58:55 GMT, Daniel Fuchs wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove ETag handling from response headers and related tests > > I haven't finished reviewing but here are some early feedback. > Also support for Range header will need to be documented in `SimpleFileServer.java`. > See https://docs.oracle.com/en/java/javase/25/docs/api/jdk.httpserver/com/sun/net/httpserver/SimpleFileServer.html#file-handler-heading Hello @dfuch, Thank you for the review. I have completed all the requested changes: formatting fixes, additional unit tests, and updates to the JavaDoc of `SimpleFileServer`. Regarding the CSR, I am not listed in the Census and therefore do not have a JBS/OpenJDK account to proceed with it. Would it be possible for you to either issue an account for me or handle the CSR on your side? If either option works, I can provide the necessary information, including the full text for the CSR ticket. Thank you very much for your understanding. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472341066 From duke at openjdk.org Fri Oct 31 10:31:53 2025 From: duke at openjdk.org (EunHyunsu) Date: Fri, 31 Oct 2025 10:31:53 GMT Subject: RFR: 8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration Message-ID: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@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. ------------- Commit messages: - JDK-8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration Changes: https://git.openjdk.org/jdk/pull/28084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371009 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 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 dfuchs at openjdk.org Fri Oct 31 10:58:11 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 10:58:11 GMT Subject: RFR: 8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration In-Reply-To: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com> References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com> Message-ID: On Fri, 31 Oct 2025 10:22:06 GMT, EunHyunsu 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. src/java.net.http/share/classes/java/net/http/HttpClient.java line 101: > 99: * .uri(URI.create("https://foo.com/")) > 100: * .build(); > 101: * Thanks for working on this patch! I would put the creation of the request after the creation of the client. Logically you would create the client first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28084#discussion_r2481023063 From michaelm at openjdk.org Fri Oct 31 11:01:11 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 31 Oct 2025 11:01:11 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 10:12:27 GMT, Peyang 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: > > Add documentation for HTTP range requests support in SimpleFileServer This looks like a useful enhancement. One comment - we probably should send the "Accept-Ranges" header in response to a HEAD request also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472517222 From michaelm at openjdk.org Fri Oct 31 11:20:03 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 31 Oct 2025 11:20:03 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 10:12:27 GMT, Peyang 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: > > Add documentation for HTTP range requests support in SimpleFileServer Also, do we need to support "If-Ranges" with this PR? It seems like it belongs more with a general "conditional requests" feature, which is probably a much bigger piece of work. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472588278 From dfuchs at openjdk.org Fri Oct 31 11:26:03 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 11:26:03 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> Message-ID: On Fri, 31 Oct 2025 10:20:08 GMT, Peyang wrote: > Regarding the CSR, I am not listed in the Census and therefore do not have a JBS/OpenJDK account to proceed with it. No problem - one of us will create the CSR, when we have setlled on the documentation and implementation changes and the PR is approved or close to be approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472611930 From duke at openjdk.org Fri Oct 31 11:40:08 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 11:40:08 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 10:58:11 GMT, Michael McMahon wrote: > One comment - we probably should send the "Accept-Ranges" header in response to a HEAD request also. Thanks for the comment. Just to note, `Accept-Ranges` is already included in responses to HEAD file requests as well, i think. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472671655 From duke at openjdk.org Fri Oct 31 11:43:02 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 11:43:02 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v3] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <1TRxwL_fho0zqIcpYeCJrRDGEkccmYWInISzIIwTMHg=.1ea78568-eebf-4936-9e4a-d0dea48c850f@github.com> Message-ID: On Fri, 31 Oct 2025 11:23:49 GMT, Daniel Fuchs wrote: > No problem - one of us will create the CSR, when we have setlled on the documentation and implementation changes and the PR is approved or close to be approved. Thank you for handling this, I really appreciate it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472682614 From michaelm at openjdk.org Fri Oct 31 11:54:06 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 31 Oct 2025 11:54:06 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 11:37:40 GMT, Peyang wrote: > > One comment - we probably should send the "Accept-Ranges" header in response to a HEAD request also. > > Thanks for the comment. Just to note, `Accept-Ranges` is already included in responses to HEAD file requests as well, i think. Ah yes. I see now that `serveFile()` is called for HEAD requests also. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28021#issuecomment-3472734502 From dfuchs at openjdk.org Fri Oct 31 11:58:12 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 11:58:12 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 10:12:27 GMT, Peyang 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: > > Add documentation for HTTP range requests support in SimpleFileServer Changes requested by dfuchs (Reviewer). src/jdk.httpserver/share/classes/com/sun/net/httpserver/SimpleFileServer.java line 95: > 93: *

Range requests

> 94: * > 95: *

The file server also supports HTTP range requests, allowing clients to To make it clear I think we should also mention the file handler: Suggestion: *

The file server and {@linkplain #createFileHandler(Path) file handler} also support HTTP * range requests, allowing clients to src/jdk.httpserver/share/classes/com/sun/net/httpserver/SimpleFileServer.java line 97: > 95: *

Suggestion: * RFC 9110.

src/jdk.httpserver/share/classes/com/sun/net/httpserver/SimpleFileServer.java line 100: > 98: * > 99: *

The server also supports conditional range requests with the {@code If-Range} > 100: * request header using a date. Suggestion: *

Conditional range requests with the {@code If-Range} * request header using a date are also supported. src/jdk.httpserver/share/classes/com/sun/net/httpserver/SimpleFileServer.java line 127: > 125: * @toolGuide jwebserver > 126: * > 127: * @since 18 Suggestion: * @spec https://www.rfc-editor.org/info/rfc9110 * RFC 9110: HTTP Semantics * * @since 18 src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 347: > 345: end = fileSize - 1; > 346: } else { // "-" or "-" > 347: start = Long.parseLong(startStr); We only want to accept base 10 numbers, don't we? Suggestion: start = Long.parseLong(startStr, 10); src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 348: > 346: } else { // "-" or "-" > 347: start = Long.parseLong(startStr); > 348: end = endStr.isEmpty() ? fileSize - 1 : Long.parseLong(endStr); Suggestion: end = endStr.isEmpty() ? fileSize - 1 : Long.parseLong(endStr, 10); src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 362: > 360: ranges.add(new RangeEntry(start, end)); > 361: } > 362: return ranges; I believe we should also return null if we haven't reached the end of the string. Can that happen? Maybe not - I'd expect the unit test to verify that. ------------- PR Review: https://git.openjdk.org/jdk/pull/28021#pullrequestreview-3403833732 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481113846 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481127260 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481130641 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481137191 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481153043 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481158906 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481163698 From dfuchs at openjdk.org Fri Oct 31 11:58:13 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 11:58:13 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 11:45:51 GMT, Daniel Fuchs wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add documentation for HTTP range requests support in SimpleFileServer > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 347: > >> 345: end = fileSize - 1; >> 346: } else { // "-" or "-" >> 347: start = Long.parseLong(startStr); > > We only want to accept base 10 numbers, don't we? > > Suggestion: > > start = Long.parseLong(startStr, 10); Maybe we should additionally reject startStr if it begins with '+' > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 348: > >> 346: } else { // "-" or "-" >> 347: start = Long.parseLong(startStr); >> 348: end = endStr.isEmpty() ? fileSize - 1 : Long.parseLong(endStr); > > Suggestion: > > end = endStr.isEmpty() ? fileSize - 1 : Long.parseLong(endStr, 10); and same here - we should additionally reject endStr if it starts with '+' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481156352 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481160730 From dfuchs at openjdk.org Fri Oct 31 12:12:19 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 12:12:19 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 10:12:27 GMT, Peyang 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: > > Add documentation for HTTP range requests support in SimpleFileServer src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 310: > 308: return true; > 309: } > 310: servePartialContents(exchange, path, ranges); The RFC says: > A server that supports range requests MAY ignore or reject a [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header field that contains an invalid [ranges-specifier](https://www.rfc-editor.org/rfc/rfc9110.html#rule.ranges-specifier) ([Section 14.1.1](https://www.rfc-editor.org/rfc/rfc9110.html#range.specifiers)), a [ranges-specifier](https://www.rfc-editor.org/rfc/rfc9110.html#rule.ranges-specifier) with more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since these are indications of either a broken client or a deliberate denial-of-service attack ([Section 17.15](https://www.rfc-editor.org/rfc/rfc9110.html#overlapping.ranges)). I would expect a validation of the ranges list before we serve them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481206652 From michaelm at openjdk.org Fri Oct 31 12:46:16 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 31 Oct 2025 12:46:16 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: <48O5S00LSWzLiTxQvJDFHv6xDe6pQ6HqCGsq-JSKl6c=.5a4e169b-76a3-4af3-b4a5-2dd258e93a28@github.com> On Fri, 31 Oct 2025 10:12:27 GMT, Peyang 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: > > Add documentation for HTTP range requests support in SimpleFileServer Changes requested by michaelm (Reviewer). A couple more instances src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 388: > 386: for (RangeEntry range : ranges) { > 387: if (!isSingleRange) { > 388: os.write(("--" + boundary + "\r\n").getBytes(UTF_8)); Suggestion: os.write(("--" + boundary + "\r\n").getBytes(US_ASCII)); Need to import the constant also. src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 391: > 389: os.write(("Content-Type: " + fileContentType + "\r\n").getBytes(UTF_8)); > 390: os.write("Content-Range: bytes %s-%s/%s\r\n\r\n" > 391: .formatted(range.start, range.end, fileSize).getBytes(UTF_8)); Suggestion: .formatted(range.start, range.end, fileSize).getBytes(US_ASCII)); src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 391: > 389: os.write(("Content-Type: " + fileContentType + "\r\n").getBytes(UTF_8)); > 390: os.write("Content-Range: bytes %s-%s/%s\r\n\r\n" > 391: .formatted(range.start, range.end, fileSize).getBytes(UTF_8)); Suggestion: os.write(("Content-Type: " + fileContentType + "\r\n").getBytes(US_ASCII)); os.write("Content-Range: bytes %s-%s/%s\r\n\r\n" .formatted(range.start, range.end, fileSize).getBytes(US_ASCII)); src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 405: > 403: } > 404: if (!isSingleRange) { > 405: os.write("\r\n".getBytes(UTF_8)); Suggestion: os.write("\r\n".getBytes(US_ASCII)); src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 410: > 408: if (!isSingleRange) { > 409: String closingBoundary = "--" + boundary + "--\r\n"; > 410: os.write(closingBoundary.getBytes(UTF_8)); Suggestion: os.write(closingBoundary.getBytes(US_ASCII)); ------------- PR Review: https://git.openjdk.org/jdk/pull/28021#pullrequestreview-3404070866 Changes requested by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28021#pullrequestreview-3404106366 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481272262 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481273046 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481288301 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481273795 PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481274233 From myankelevich at openjdk.org Fri Oct 31 12:54:42 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 31 Oct 2025 12:54:42 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v4] In-Reply-To: References: Message-ID: > 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). Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: removed unneeded thread for exchange completion in shouldCompleteAfterDelay ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27670/files - new: https://git.openjdk.org/jdk/pull/27670/files/7dd7cc8c..da770151 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27670&range=02-03 Stats: 13 lines in 1 file changed: 0 ins; 11 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27670.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27670/head:pull/27670 PR: https://git.openjdk.org/jdk/pull/27670 From myankelevich at openjdk.org Fri Oct 31 12:54:43 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Fri, 31 Oct 2025 12:54:43 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v3] In-Reply-To: References: Message-ID: <-0hpUGtGQ0OLZu_TxmXGCKBmAjYnEwKBBWu57SXg0-4=.698f7a63-9418-49ab-bf4e-59568d4c8b4d@github.com> On Wed, 29 Oct 2025 18:12:22 GMT, Daniel Fuchs wrote: >> Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: >> >> comments > > test/jdk/com/sun/net/httpserver/ServerStopTerminationTest.java line 171: > >> 169: >> 170: // Complete the exchange 10 second into the future. >> 171: // Runs in parallel, so won't block the server stop > > when we reach here the server has already been stopped. > So: > > 1. the comment is inaccurate. > 2. we don't need the virtual thread or the exchangeDuration here. Just call countDown on the latch directly. > 3. the first check `elapsed >= exchangeDuration.toNanos()` is not needed - since `exchangeDuration` is not needed. Changed in the next commit ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27670#discussion_r2481311305 From duke at openjdk.org Fri Oct 31 12:58:39 2025 From: duke at openjdk.org (EunHyunsu) Date: Fri, 31 Oct 2025 12:58:39 GMT Subject: RFR: 8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration [v2] 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: > 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 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28084/files - new: https://git.openjdk.org/jdk/pull/28084/files/34421a70..0c799d0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28084&range=00-01 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 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 Fri Oct 31 12:58:40 2025 From: duke at openjdk.org (EunHyunsu) Date: Fri, 31 Oct 2025 12:58:40 GMT Subject: RFR: 8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration [v2] In-Reply-To: References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com> Message-ID: On Fri, 31 Oct 2025 10:55:14 GMT, Daniel Fuchs wrote: >> 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 > > src/java.net.http/share/classes/java/net/http/HttpClient.java line 101: > >> 99: * .uri(URI.create("https://foo.com/")) >> 100: * .build(); >> 101: * > > Thanks for working on this patch! > > I would put the creation of the request after the creation of the client. Logically you would create the client first. Thank you for the review! I?ve updated the example to create the client before the request, as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28084#discussion_r2481322425 From mdonovan at openjdk.org Fri Oct 31 13:09:23 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 31 Oct 2025 13:09:23 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v4] In-Reply-To: References: Message-ID: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: removed unnecessary comment and made getSSLContext(...) private ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27342/files - new: https://git.openjdk.org/jdk/pull/27342/files/4804c90d..94ea9ba7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=02-03 Stats: 22 lines in 6 files changed: 0 ins; 13 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/27342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342 PR: https://git.openjdk.org/jdk/pull/27342 From mdonovan at openjdk.org Fri Oct 31 13:09:26 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 31 Oct 2025 13:09:26 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v3] In-Reply-To: References: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> Message-ID: On Thu, 30 Oct 2025 21:56:15 GMT, Artur Barashev wrote: >> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: >> >> changed tests to use SecurityUtils.removeDisabled*Algs methods > > test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221: > >> 219: if (args[1].contains("MD5")) { >> 220: // MD5 is used in this test case, don't disable MD5 algorithm. >> 221: SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms", > > Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests. I removed the comment entirely. It seemed redundant to say "if MD5 is used" right below the `if(args[0].equals("MD5")` > test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 184: > >> 182: SSLContext ctx = SSLContext.getInstance(protocol); >> 183: >> 184: if (keyCert != null) { > > Why do we check for keyCert being `null`? Do we expect some future tests to make use of it? BTW, in such case `CertificateBuilder.printCertificate` would fail first. I think that was leftover from refactoring the code. I removed the null checks and made the method private for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481353898 PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481352676 From duke at openjdk.org Fri Oct 31 13:41:52 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 13:41:52 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v7] 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: > 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 four additional commits since the last revision: - Use US-ASCII encoding for HTTP headers in FileServerHandler Co-authored-by: Michael McMahon - Reject HTTP Range requests with "+" prefix and enhance invalid range header tests Co-authored-by: Daniel Fuchs - Fix parsing of HTTP Range header by specifying radix for Long.parseLong Co-authored-by: Daniel Fuchs - Update documentation for HTTP range requests in SimpleFileServer Co-authored-by: Daniel Fuchs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28021/files - new: https://git.openjdk.org/jdk/pull/28021/files/1ed7f76f..10872b75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28021&range=05-06 Stats: 31 lines in 3 files changed: 10 ins; 0 del; 21 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 Fri Oct 31 13:44:04 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 31 Oct 2025 13:44:04 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 10:12:27 GMT, Peyang 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: > > Add documentation for HTTP range requests support in SimpleFileServer src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 399: > 397: int len = raf.read(buffer, 0, (int) Math.min(buffer.length, bytesToWrite)); > 398: if (len == -1) { > 399: break; // EOF Is this not an error situation, if we reach EOF and have only partially returned the requested range? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481472303 From duke at openjdk.org Fri Oct 31 13:51:05 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 13:51:05 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 11:50:28 GMT, Daniel Fuchs wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add documentation for HTTP range requests support in SimpleFileServer > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 362: > >> 360: ranges.add(new RangeEntry(start, end)); >> 361: } >> 362: return ranges; > > I believe we should also return null if we haven't reached the end of the string. Can that happen? Maybe not - I'd expect the unit test to verify that. Thanks, that's covbered. Any incomplete or malformed spec including trailing commas or spaces returns `null` and the new unit tests verify this behavior. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481489277 From duke at openjdk.org Fri Oct 31 14:07:14 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 14:07:14 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 12:09:59 GMT, Daniel Fuchs wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add documentation for HTTP range requests support in SimpleFileServer > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 310: > >> 308: return true; >> 309: } >> 310: servePartialContents(exchange, path, ranges); > > The RFC says: > >> A server that supports range requests MAY ignore or reject a [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header field that contains an invalid [ranges-specifier](https://www.rfc-editor.org/rfc/rfc9110.html#rule.ranges-specifier) ([Section 14.1.1](https://www.rfc-editor.org/rfc/rfc9110.html#range.specifiers)), a [ranges-specifier](https://www.rfc-editor.org/rfc/rfc9110.html#rule.ranges-specifier) with more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since these are indications of either a broken client or a deliberate denial-of-service attack ([Section 17.15](https://www.rfc-editor.org/rfc/rfc9110.html#overlapping.ranges)). > > I would expect a validation of the ranges list before we serve them. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481541467 From abarashev at openjdk.org Fri Oct 31 14:24:21 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 31 Oct 2025 14:24:21 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v3] In-Reply-To: References: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com> Message-ID: On Fri, 31 Oct 2025 13:06:48 GMT, Matthew Donovan wrote: >> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221: >> >>> 219: if (args[1].contains("MD5")) { >>> 220: // MD5 is used in this test case, don't disable MD5 algorithm. >>> 221: SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms", >> >> Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests. > > I removed the comment entirely. It seemed redundant to say "if MD5 is used" right below the `if(args[0].equals("MD5")` Yes, makes sense. Please also fix the line length. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481598670 From dfuchs at openjdk.org Fri Oct 31 14:48:19 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 14:48:19 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 14:04:49 GMT, Peyang wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 310: >> >>> 308: return true; >>> 309: } >>> 310: servePartialContents(exchange, path, ranges); >> >> The RFC says: >> >>> A server that supports range requests MAY ignore or reject a [Range](https://www.rfc-editor.org/rfc/rfc9110.html#field.range) header field that contains an invalid [ranges-specifier](https://www.rfc-editor.org/rfc/rfc9110.html#rule.ranges-specifier) ([Section 14.1.1](https://www.rfc-editor.org/rfc/rfc9110.html#range.specifiers)), a [ranges-specifier](https://www.rfc-editor.org/rfc/rfc9110.html#rule.ranges-specifier) with more than two overlapping ranges, or a set of many small ranges that are not listed in ascending order, since these are indications of either a broken client or a deliberate denial-of-service attack ([Section 17.15](https://www.rfc-editor.org/rfc/rfc9110.html#overlapping.ranges)). >> >> I would expect a validation of the ranges list before we serve them. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481667982 From dfuchs at openjdk.org Fri Oct 31 14:56:06 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 14:56:06 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: On Fri, 31 Oct 2025 13:41:47 GMT, Michael McMahon wrote: >> Peyang has updated the pull request incrementally with one additional commit since the last revision: >> >> Add documentation for HTTP range requests support in SimpleFileServer > > src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 399: > >> 397: int len = raf.read(buffer, 0, (int) Math.min(buffer.length, bytesToWrite)); >> 398: if (len == -1) { >> 399: break; // EOF > > Is this not an error situation, if we reach EOF and have only partially returned the requested range? Good point. But we have already sent the status code. I guess we should throw IOException in this case, so that the ServerImpl closes the connection, ensuring that the client notices that the response was not entirely fulfilled? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481693671 From mdonovan at openjdk.org Fri Oct 31 15:02:42 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Fri, 31 Oct 2025 15:02:42 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v5] In-Reply-To: References: Message-ID: > This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: changed line wrapping ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27342/files - new: https://git.openjdk.org/jdk/pull/27342/files/94ea9ba7..1aaf4247 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=03-04 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342 PR: https://git.openjdk.org/jdk/pull/27342 From michaelm at openjdk.org Fri Oct 31 15:11:43 2025 From: michaelm at openjdk.org (Michael McMahon) Date: Fri, 31 Oct 2025 15:11:43 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> Message-ID: <9dX_Pl6xcwpO1YgLTj_L3qkGj_Dgrbo3VS3iiztbejo=.bdd88636-83dd-44cf-8edc-c4f8fcfa1ca4@github.com> On Fri, 31 Oct 2025 14:53:38 GMT, Daniel Fuchs wrote: >> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java line 399: >> >>> 397: int len = raf.read(buffer, 0, (int) Math.min(buffer.length, bytesToWrite)); >>> 398: if (len == -1) { >>> 399: break; // EOF >> >> Is this not an error situation, if we reach EOF and have only partially returned the requested range? > > Good point. But we have already sent the status code. I guess we should throw IOException in this case, so that the ServerImpl closes the connection, ensuring that the client notices that the response was not entirely fulfilled? 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481741264 From duke at openjdk.org Fri Oct 31 15:17:53 2025 From: duke at openjdk.org (Peyang) Date: Fri, 31 Oct 2025 15:17:53 GMT Subject: RFR: 8355572: Support HTTP Range requests in Simple Web Server [v6] In-Reply-To: <9dX_Pl6xcwpO1YgLTj_L3qkGj_Dgrbo3VS3iiztbejo=.bdd88636-83dd-44cf-8edc-c4f8fcfa1ca4@github.com> References: <2Lue7uj_ciz7rRsleMm4w5VJ1UFGsAdqpADjkVnC-O0=.793be549-e1e8-40a6-836d-b562d6b9f308@github.com> <9dX_Pl6xcwpO1YgLTj_L3qkGj_Dgrbo3VS3iiztbejo=.bdd88636-83dd-44cf-8edc-c4f8fcfa1ca4@github.com> Message-ID: On Fri, 31 Oct 2025 15:08:50 GMT, Michael McMahon wrote: >> Good point. But we have already sent the status code. I guess we should throw IOException in this case, so that the ServerImpl closes the connection, ensuring that the client notices that the response was not entirely fulfilled? > > 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. There fore, I don't thiunk 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 editing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28021#discussion_r2481765572 From dfuchs at openjdk.org Fri Oct 31 15:22:13 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 15:22:13 GMT Subject: RFR: 8368625: com/sun/net/httpserver/ServerStopTerminationTest.java fails intermittently [v4] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 12:54:42 GMT, Mikhail Yankelevich 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). > > Mikhail Yankelevich has updated the pull request incrementally with one additional commit since the last revision: > > removed unneeded thread for exchange completion in shouldCompleteAfterDelay LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27670#pullrequestreview-3404786725 From dfuchs at openjdk.org Fri Oct 31 15:26:15 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 15:26:15 GMT Subject: RFR: 8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration [v2] In-Reply-To: References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com> Message-ID: On Fri, 31 Oct 2025 12:58:39 GMT, EunHyunsu 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 src/java.net.http/share/classes/java/net/http/HttpClient.java line 124: > 122: * .thenApply(HttpResponse::body) > 123: * .thenAccept(System.out::println); } > 124: * The POST snippet doesn't have the creation of the client, but I believe it's OK because the creation of the client is shown in the snippet just above. In addition, we don't want to seem to promote creating a new client for each new request. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28084#discussion_r2481792322 From dfuchs at openjdk.org Fri Oct 31 15:29:08 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 31 Oct 2025 15:29:08 GMT Subject: RFR: 8371009: HttpClient javadoc synchronous example missing HttpRequest variable declaration [v2] In-Reply-To: References: <3uKkSjIMFIHxX6-4LmTsKakoC6DEG2s80eUw-4D8uoU=.00e81e1c-85d8-4bc7-be97-31aa7a406170@github.com> Message-ID: On Fri, 31 Oct 2025 12:58:39 GMT, EunHyunsu 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? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28084#issuecomment-3473590204 From abarashev at openjdk.org Fri Oct 31 16:08:40 2025 From: abarashev at openjdk.org (Artur Barashev) Date: Fri, 31 Oct 2025 16:08:40 GMT Subject: RFR: 8353738: Update TLS unit tests to not use certificates with MD5 signatures [v5] In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan wrote: >> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > changed line wrapping LGTM ------------- Marked as reviewed by abarashev (Committer). PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3405000667

The file server also supports HTTP range requests, allowing clients to > 96: * request partial file content using the {@code Range} request header, as specified in > 97: * RFC 9110.