jdk.httpserver 101 status code closing connection

[Daniel Fuchs]

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