On Fri, 10 Oct 2025 14:31:24 GMT, Josiah Noel <[email protected]> wrote:
> It occurs to me, that there is actually no practical reason for this PR. For > the 100-continue case, there are better ways to handle it than > `sendResponseHeaders` or even a new public `sendIntermediateResponse` method. > The best method I think would be to be like jetty and move the > auto-send-continue logic to when the inputstream is read. This is because > trying to read the input stream implies that you're okay to receive the body. > > For connection upgrades, this PR is also unrelated as besides keeping the > inputstream open, it otherwise behaves like other status codes and doesn't > require sending 101 and then some other status. Possibly. If we are agreed that 100 Continue is the only potential practical use case for this (other than 101 which is out of scope), then we definitely don't need a new method at this time, and we then need to ask what point is there in sending a 100 Continue considering that the server already handles it. Is there a use case for allowing the user to send it separately? If not, I'm questioning the benefit of allowing it. As I said from the start, this was never intended to be supported in the initial implementation and my first thought was just to disallow it formally. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27069#issuecomment-3396710368
