Verdict: ✅ Approve — excellent fix for a real connection leak that could cause deadlocks in production.

What's great

The production fixes are correct and well-targeted:

• JdkTransporter implPut(): adds the missing finally { closeBody(response); } — this was the core bug. closeBody is already null-safe (checks streamHttpResponse != null), so the response = null initialization is safe.
• JdkTransporter implGet(): clean simplification — removes redundant inner closeBody() calls since the outer finally already handles all exit paths.
• JettyTransporter implPut(): wrapping InputStreamResponseListener in try-with-resources and moving RFC 9457 handling inside ensures the listener is always closed. The HttpTransporterException still propagates correctly (it's not caught by the ExecutionException catch block).
• Connection leak detection in tearDown() is a force multiplier — every existing HTTP transporter test now doubles as a leak detector.

Suggestions

1. Null guard before Awaitility check (HttpTransporterTest.java, line ~309)

The Awaitility assertion runs before the if (httpServer != null) check. If setUp() fails before creating the server, @AfterEach still runs and the lambda will NPE, masking the real failure:

// Current:
Awaitility.await().atMost(5, TimeUnit.SECONDS).until(() -> httpServer.getNumConnectedEndPoints() == 0);
if (httpServer != null) {

// Suggested — move inside the null guard:
if (httpServer != null) {
    Awaitility.await().atMost(5, TimeUnit.SECONDS).until(() -> httpServer.getNumConnectedEndPoints() == 0);
    httpServer.stop();
    httpServer = null;
}

2. HTTP 204 with response body — may weaken the test (HttpServer.java, PUT handler)

The response body is written, then status is set to SC_NO_CONTENT (204). Per RFC 9110 §6.4.1, 204 responses should have no content. While Jetty will still put the bytes on the wire, some HTTP client implementations may skip draining the body for 204, which could make the test pass even without the fix. Consider using SC_OK (200) when responseBodyForPut is set so the test is unambiguous:

if (responseBodyForPut != null) {
    writeResponseBodyMessage(req, response, responseBodyForPut);
    response.setStatus(HttpServletResponse.SC_OK);
} else {
    response.setStatus(HttpServletResponse.SC_NO_CONTENT);
}

Minor observations (no action needed)

• Double closeBody in implPut: The inner try { ... } finally { closeBody(response); } around error handling is now redundant with the new outer finally. Harmless (idempotent close), but in implGet the equivalent was cleaned up — consistency could be improved.
• Hardcoded Awaitility version: 4.3.0 is hardcoded in maven-resolver-test-http/pom.xml rather than managed in the parent POM's <dependencyManagement>.
• Pre-existing: JettyTransporter.implGet() also creates InputStreamResponseListener without try-with-resources — the same pattern this PR fixes in implPut(). Might be worth a follow-up.

CI: ⏳ All pending (just un-drafted). Production code changes are straightforward enough to review without CI, but will want to confirm all tests pass.

Reviewed with AI assistance on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.

Follow-up review (commit 2/2): ✅ All suggestions addressed — looks great.

• Null guard: Awaitility check correctly moved inside if (httpServer != null) ✓
• PUT response status: Using SC_CREATED (201) instead of SC_NO_CONTENT (204) when a body is present — even better than the 200 I suggested, since 201 is the semantically correct success status for PUT-creates-resource ✓
• Awaitility version: Centralized in parent POM <dependencyManagement>, with a helpful note about the 4.3.1 release issue ✓
• Double closeBody in implPut: Inner try/finally removed, now consistent with implGet simplification ✓

No further comments.

Reviewed with AI assistance on behalf of @gnodet. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.