On Tue, 26 May 2026 04:28:55 GMT, Josiah Noel <[email protected]> wrote:

>> Josiah Noel has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - lint
>>  - exclude http/1.0
>>  - constant
>>  - will not upgrade when there is a body
>>  - Update UpgradeOutputStream.java
>>  - Merge branch 'openjdk:master' into JDK-8368695
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/5caa357f...754e48e1
>
> To be fair, the httpserver isn't super popular, so the team probably has 
> higher priority PR's to review. I can easily see a world where I continue 
> `/touch`ing this PR for the next couple years, nothing to do but wait 
> patiently I suppose.

Thanks @SentryMan for keeping this alive and addressing all the feedback so 
thoroughly.

I'd like to add a use-case perspective from the field:
`jdk.httpserver` has become genuinely useful for lightweight REST APIs, 
integration tests, and small in-process services — precisely *because* it has 
zero external dependencies.
Protocol upgrade (101) is the one capability that blocks building WebSocket 
endpoints or raw-socket tunnels on top of it without pulling in a third-party 
server.
The JDK HTTP *client* already has full WebSocket support; having no 
corresponding server-side escape hatch feels asymmetric.

The change itself is well-scoped:

- **Opt-in** — only activates when the handler explicitly calls 
`sendResponseHeaders(101, 0)`; existing handlers are not affected.
- **Minimal surface** — no new public API types, just changed stream lifecycle 
behavior for a specific status code.
- **Design-validated** — backward compatibility concern was raised and 
addressed; documentation was drafted collaboratively.

I understand the team has higher-priority work, but given that the design 
discussion appears complete and the contributor has been patient for months, 
I'd love to see this land in an upcoming release.
Is there anything still blocking a formal review sign-off, or a way the 
community can help move this forward?

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

PR Comment: https://git.openjdk.org/jdk/pull/27989#issuecomment-4541381457

Reply via email to