On Thu, 9 Oct 2025 14:35:59 GMT, Daniel Fuchs <[email protected]> wrote:
>> Josiah Noel has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Update InputRead100Test.java >> - actually fail if sent twice > > Noted. But https://www.rfc-editor.org/rfc/rfc7231.html#section-6.2 >> 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. > > I don't see anything hinting that 100 should be special in this respect. > @dfuch i agree. I don’t think there is anything to do here. The 100-Continue > is already properly sent - if a bit limited. I think the ability to ‘switch > protocols’ is a different bug. So what exactly needs to be fixed here? We want to be able to send N 1xx response codes before sending the final response, without `sendResponseHeaders` considering that the final response has been sent, or that the output stream needs to be closed. At this point we are not interested in the semantics of the 1xx codes. They will either be recognized and handled by the client, or not recognized and discarded. Adhering to the semantics of the code should be the business of the application that sends them. For 100 we could envisage a followup to provide some means for the application to control whether it wants to send 100 or 417. For 101 I am still not convinced we should support it - but that can be discussed - though not in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3386241887
