Hi Josia,
Unfortunately I can't look at that PR until the OCA
has been signed and processed.
That said I'd be worried about several potential issues:
- will the server keep a reference to the connection/socket
so that it can be closed if HttpServer::close is called?
- how will the server know that the stream/connection
has been closed so that the above reference can be
removed, and stop can return early
- would there be a need to adjust any of the various timers that
the server maintains?
- if HttpServer::stop is called before the connection is
closed, what happens?
- will/should the Handler implementation return after acquiring
the streams? Or after having closed them?
etc...
There may be a lot of corner cases in there that will need to
be tested, and maintained, and supported.
best regards,
-- daniel
On 03/09/2025 13:31, Josiah Noel wrote:
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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/27069__;!!ACWV5N9M2RV99hQ!JOxb2ls3Lkvn31MUo0cJkXKCVB9LU1okVBNXGBsZMDk9TfdS5ZcnZoBTyNe8epT9YnnfCEbpmuQkINHFTYT_hQ$>. 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
