jdk.httpserver 101 status code closing connection

[Josiah Noel]

>
> Unfortunately I can't look at that PR until the OCA
> has been signed and processed.


Yeah, I put it in draft for now until that goes through. I had signed for
helidon and not OpenJDK I guess

- if HttpServer::stop is called before the connection is
>    closed, what happens?


Testing locally, when stop is called after sending the 101, the connection
is closed, and an AsynchronousCloseException is thrown if you try to
continue reading the body input stream. The executor will also cancel the
request as usual

If stop is called after sending the 101 and the body is never read, the
request is canceled as usual. It doesn't appear to hang or anything.

- will/should the Handler implementation return after acquiring
>    the streams? Or after having closed them?


Returning would end the request like it does today.

- 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


I don't understand why we need to keep a reference if we expect the handler
to manage the stream.

On Wed, Sep 3, 2025 at 9:24 AM Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/net-dev/attachments/20250903/9a7084b9/attachment-0001.htm>