On Wed, 15 Oct 2025 16:10:02 GMT, Michael McMahon <[email protected]> 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
