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

[Michael McMahon]

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 have to say I'm a bit uncomfortable trying to shoe-horn all this functionality into the existing method `sendResponseHeaders`. There are significant behavioral implications for the server with each of the `1XX` intermediate response codes. Take `103 early Hints` for example. That is usually sent with a `Link` header in the intermediate response. Where would the header come from? If it's the response headers returned from `getResponseHeaders` then is this map cleared after the intermediate response or is the user supposed to clear it? Does this work?

If we are supporting `100 Continue` now (under user control) does the expected behavior work? If a client sends a request with an `Expect: 100-Continue` header and waits for the intermediate response before sending the request body, does this actually work? I know we have partial support for it already. But, I'd like to see tests and apidoc documenting all of this before we consider adding it.

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

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