jdk.httpserver 101 status code closing connection

[Josiah Noel]

> The current code has some provision for some one hundred
> codes but sendResponseHeaders appears not to have been
> designed to send interim responses


A new method to send interim response codes might be better

than trying to shoehorn sending one hundreds with the

current API, but we haven't investigated that yet.



As the JIRA issue notes, there is nothing in the javadocs that suggests
that sending informational codes with the current API closes the streams.
Merely teaching the exchange that 101 status codes should not enforce
content-length -1 is enough.


> Making it possible to handle protocols like WebSocket from
> within a Handler/Filter would bring that to the next level
> though, and I suspect more surgery would be needed.
> I am not sure it is something we would be looking forward
> to support this in the long run.



Indeed, if you were to add code to process WebSocket frames, that would be
yet another thing to maintain long-term, which is why I'm not suggesting
it. Not closing access to the streams is good enough to allow the consumer
to implement WebSockets. While I do also have code to process the frames,
that is out of scope for the issue at hand.

I've raised a one-file PR illustrating the changes I'm talking about
<https://github.com/openjdk/jdk/pull/27069>. If you could spare time to
briefly skim it over to get a better sense of what I'm talking about, I
would be most grateful.

Thanks for your time,

-- Josiah
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250903/6a517f5a/attachment-0001.htm>