RFR: 8368695: Support 101 switching protocol in jdk.httpserver [v5]

[Michael McMahon]

On Wed, 15 Oct 2025 16:10:02 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>>> > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching
>>> > the underlying connection from the HTTP stack.
>>> 
>>> Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams.
>> 
>> Well - no. The connection will be reused for the next request when the chunked streams are closed.
>> 
>>  
>>> > Closing the exchange after {@code
>>> > sendResponseHeaders(101, -1)} has been called has no effect on these streams.
>>> 
>>> Doesn't closing the exchange call close on both the input/output stream?
>> 
>> We may need to link back to the upgrade paragraph in `HttpExchange::close`. Good remark.
>> The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective.
>
>> > > Sending a 101 response to a request from the client to upgrade to some other protocol has the effect of detaching
>> > > the underlying connection from the HTTP stack.
>> > 
>> > 
>> > Isn't the behavior the same as with regular chunked encoding? Do we need a note for that as well? In both cases we aren't exactly passing a reference to the raw streams.
>> 
>> Well - no. The connection will be reused for the next request when the chunked streams are closed.
>> 
> 
> Chunked encoding does not expose the "raw" socket either. There is a framing structure (though primitive)
> associated with each chunk.
> 
>> > > Closing the exchange after {@code
>> > > sendResponseHeaders(101, -1)} has been called has no effect on these streams.
>> > 
>> > 
>> > Doesn't closing the exchange call close on both the input/output stream?
>> 
>> We may need to link back to the upgrade paragraph in `HttpExchange::close`. Good remark. The notion of "HTTP exchange" doesn't really make sense after the protocol is upgraded. That is - the HTTP/1.1 exchange should be considered closed as soon as the upgrade is effective.

> Thanks @Michael-Mc-Mahon for driving this discussion. Would this text be normative - that it - would any implementation plugged through the SPI need to support this? If not we should find some way to tie that to the JDK built-in implementation. I know that the HttpServer API itself is not part of the Java SE spec - but maybe we should set some expectations of what an implementation plugged through the SPI must, should, or might do.

Maybe we could allow sendResponseHeaders to throw `UnsupportedOperationException` if the function is not supported. That would be a fully compatible change I think.

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

PR Comment: https://git.openjdk.org/jdk/pull/27751#issuecomment-3407263610