HTTP/3: SocketsHttpHandler.ConnectCallback

[JamesNK]

I looked at the source for SocketsHttpHandler and it doesn't appear to use ConnectCallback when making a HTTP/3 connection.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I looked at the source for SocketsHttpHandler and it doesn't appear to use ConnectCallback when making a HTTP/3 connection.

Author:	JamesNK
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	-

[geoffkizer]

Yeah, this is not implemented yet.

What specific capability are you looking for here?

Because HTTP3 works on top of QUIC, this specific callback can't support replacing the QUIC connection -- it works in terms of Stream.

If the desire here is to control the establishment of the QUIC connection, then we would need a new API like QuicConnectCallback. However, there is currently no equivalent of Stream for QUIC, that is, an abstraction for a multiplexed connection. That means you couldn't replace the QUIC connection with an arbitrary implementation, which limits the usefulness of this.

[JamesNK]

I was thinking about it in the context of #45246 (comment)

[scalablecory]

I was thinking about it in the context of #45246 (comment)

In practice, just making a "GET /" would be just as good for establishing the connection without a meaningful request right?

[ManickaP]

Triage: we should have this in 6.0

[geoffkizer]

Hi Triage,

What specific capability are you looking for here?

See my comment above.

[karelz]

Triage: We believe this is not technically possible, closing.

[scalablecory]

@karelz we should have a QuicConnectCallback at some point; I think ideally 7.0. Is this tracked elsewhere?

[wfurt]

Is that even feasible @scalablecory? For h1/2 you can get back Stream but I don't think that is sufficient for QUIC.

[scalablecory]

Is that even feasible @scalablecory? For h1/2 you can get back Stream but I don't think that is sufficient for QUIC.

Right, the existing callback does not work. But, we still need a new one to enable that same functionality for QUIC, for the same reasons as the current callback existing.

An idea (we've talked about this a few times before) to explore for this:

• Make QuicConnection and QuicStream abstract.
• Make a static QuicConnection.ConnectAsync(...) that returns an internal MsQuic-backed connection.
• Make QuicConnectCallback return a QuicConnection.