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

I checked the rfc and it allows sending headers with 100 Continue even. Not sure why many websites (and AI) state that it cannot contain headers.

RFC 9110

> A 1xx response is terminated by the end of the header section; it cannot contain content or trailers.
> 
> A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.

Still, all of the examples I found showed no additional headers.

It still seems problematic from a server api standpoint, and would seem that sendResponseHeaders() for a 1xx should send and clear, but that would certainly break everything. 

which is why a sendInfoResponse(code,headers) seems to make the most sense to me, and the default implementation has  blank headers.

but the sendInfoResponse() is probably not sufficient - as then every handler would need to handle 'Expect: 100-Continue' which doesn't seem right. Which means the server should automatically send it if needed and the handler/filter hasn't sent it.

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

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