ConnectCallback's context.InitialRequestMessage has misleading lifetime (not tied to the Connection)

[MihaZupan]

The ConnectCallback is provided with a SocketsHttpConnectionContext that includes the InitialRequestMessage.
By the time the callback runs, the initial request may have already been completed and returned to the user, or it is being sent by a different connection. That is, a different thread may be accessing the headers while the callback is running.

As a result, any access of InitialRequestMessage's headers is problematic.

Related: #61798, #65379

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

Issue Details

---

The ConnectCallback is provided with a SocketsHttpConnectionContext that includes the InitialRequestMessage.
By the time the callback runs, the initial request may have already been completed and returned to the user, or it is being sent by a different connection. That is, a different thread may be accessing the headers while the callback is running.

As a result, any access of InitialRequestMessage's headers is problematic.

Related: #61798, #65379

Author:	MihaZupan
Assignees:	-
Labels:	bug, area-System.Net.Http
Milestone:	-

[stephentoub]

I assume this is due to the change in .NET 6 that enables a different connection to service the request if one becomes available before this connection has been established?

[MihaZupan]

Exactly.

[stephentoub]

In general that change would seem to have broken the notion of "InitialRequestMessage", since it's not necessarily. That's still the request that made the system decide to inject another connection, but it's not necessarily the first one to use it, or even use it at all.

[karelz]

Triage:

• Might be good to know how often InitialRequestMessage is used -- perhaps Obsolete it?
• More discussion is needed

[MihaZupan]

Note that this isn't only specific to headers, but anything exposed on HttpRequestMessage.

Headers are the most likely to show up as exceptions, but the ownership of the object is a problem for all the properties.
The user is free to observe/change the properties (Uri / headers / method / Options) after the request is finished, and may not expect those changes to happen while in ConnectCallback.

Worst-case, a user may be reusing the request object entirely (something we don't guard against via HttpMessageInvoker) or using it as a builder for subsequent requests (real scenario).
This could lead to the connect callback establishing a connection to an unrelated endpoint for a wrong connection pool.

[karelz]

Team discussion

Options:

1. Go back to original behavior of associating request with connection and let it block on it
2. Hand over copy of HttpRequestMessage
3. Obsolete it / analyzer + add different properties into the context
4. Make it opt-in
5. Guarantee availability of InitialRequest until first await in the method
6. Add back headers synchronization (although it does not address reusing of requests / modifying it - that would have to be documented)
7. Analyzer to warn against accessing headers in ConnectCallback (in combo with documenting against modifying request as in above)
8. Nullable InitialRequest - as soon as you access it from context, we would "lock it" for the thread

Note: Also PlainTextFilter gets the InitialRequest - that needs to be addressed / documented as well.

We are leaning towards [3].
Perhaps either way do [6].

[karelz]

Continued triage:

• @MihaZupan has solution [6] with little overhead on fast path (in combo with HttpHeaders should not remove invalid values during validating access #67199)
• [3] is needed only for rare cases when users modify the request after processing.
  • As first step we could just document it in the callback
  • We could wait for first users to report it
  • We could ask API review for their opinion
  • Decision: Let's do low-hanging work now -- document. Moving to 7.0. Once that is done, we will move it to Future and wait for reports of problems before we invest more.