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

[robert engels]

On Tue, 23 Sep 2025 17:43:42 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
>
> Josiah Noel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InputRead100Test.java

There is another issue with using sendResponseHeaders() for the interim responses. A filter could add response headers. when you call the sendResponseHeaders() it sends all of the headers, meaning you would send headers at this time which aren't valid. You would also send them again when you send the final response. A '103 Early Hints' does allow you to send additional headers at this time.

It seems more appropriate that 100 is handled internally like Jetty does, or a new method is added sendInformationalHeaders(code,headers) that doesn't take a content length, and only sends the headers for a 103 response.

103 is really only supported (recommended) with HTTP2 so it may not matter.

The server could easily be changed to never send the headers with a 1xx response.

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

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