Closed
Description
Moving the remaining items out of #83734 to make tracking easier (the changes in the original issue were backported to 6.0 and 7.0).
We should consider including more information in the System.Net.Http events:
- Request information on
RequestHeadersStart.
While we log a lot of request information inRequestStart, we may end up sending multiple requests on the wire (redirects, retries) as part of a single RequestStart/Stop pair, and there is currently no way to tell from events where those requests are being made.
Also while we log the request version inRequestStart, there is no reliable way to get the protocol version that was actually used as a result of ALPN/version policy from events (in some cases it is implied if you see other events likeRequestLeftQueue).
The following is the same parameter signature asRequestStartwith the exception of omitting theHttpVersionPolicysince it doesn't have meaning at this layer (we already know exactly what version we're using).Alternatively, the connection-level information (scheme, host, port, version) could be left out of this event, and instead be exposed in a way where the user could map connections to requests. E.g.-void RequestHeadersStart(); +void RequestHeadersStart(string scheme, string host, int port, string pathAndQuery, byte versionMajor, byte versionMinor);
-void ConnectionEstablished(byte versionMajor, byte versionMinor) -void ConnectionClosed(byte versionMajor, byte versionMinor) +void ConnectionEstablished(byte versionMajor, byte versionMinor, long connectionId, string scheme, string host, int port, string? remoteEndPoint) +void ConnectionClosed(byte versionMajor, byte versionMinor, long connectionId) +void RequestHeadersStart(long connectionId);
- A new event indicating a redirect.
This should include the new Uri we are going to try redirecting to. I don't have a strong opinion on including the whole Uri vs separating the scheme/host/port/path...+void Redirect(string redirectUri);