RFR: 8349670: HttpServer: sending interim responses fails after JDK-7026262 [v21]

[Daniel Fuchs]

On Thu, 9 Oct 2025 18:12:52 GMT, Josiah Noel <duke at openjdk.org> wrote:

>> Following the guideline of the last comment on [JDK-8349670](https://bugs.openjdk.org/browse/JDK-8349670?focusedId=14794649&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14794649), resolves the issue where sending a 1xx status code would close the input stream, preventing the server from reading the body. 
>> 
>> - When a 1xx status code is sent by `sendResponseHeaders`, the input/output streams will not be closed prematurely.
>> - sentHeaders will not be set to true when sending 1xx status codes
>> - 100-continue will be sent automatically when trying to read the inputstream if `Expect: 100-continue` header is present
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Send1xxResponsesTest.java

I'm personally OK of adding a new API to send 1xx response.

WRT 100 I'm a bit of two minds with how to handle that. We heavily use the HttpServer to test the HttpClient HTTP/1.1 stack. In the Httpclient, we wanted to test that if the server didn't send 100, the client would send the body after a reasonable timeout. Then we wanted to test that the 100 would be ignored if it came after the client had started to send the body. We also wanted to test that additional 100 would be ignored.
At the moment we need to use a ServerSocket on the server side to do that for HTTP/1.1 because the HttpServer doesn't offer this level of granularity. Adding auto-send in `getRequestBody().read()` would not allow us to use the server to do that either. 
Another thing we wanted to test is that the client would ignore 1xx code it does not know how to handle.
I was hopping that a method to send informational response codes (wether with `sendResponseHeaders` or with a new API) would help us with testing these various scenarios.
At the same time - we want our API to be as user friendly as possible - so ability to use the server to test complex scenarios for the benefit of the client comes second. Though equally, maybe other people use our server to test their own client implementations?
So that's to explain where I'm coming from.

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

PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3390825091