WinHttpHandler can set arbitrary options on native WinHTTP

[alnikola]

In the past and now again we are seeing multiple instances of the same problem - callers of the managed HttpClient using the WinHttpHandler for HTTP/2 are facing a problem already solved in the native WinHTTP. Those solutions are enabled and configured through WinHTTP session and request options, however the users don't have access to them because the WinHttpHandler doesn't expose the corresponding API. To solve this class of problems once and for all it's proposed to add a generic passthrough mechanism so the callers can query and set options on the WinHTTP session and request handles.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[scalablecory]

This doesn't seem unreasonable, though I'd like to see some interest here before moving forward.

[jabbera]

@alnikola can you comment on what issues you are seeing? I was looking at adopting this for .net framework for calling azure functions. I don't want to stumble across a ton of issues.

[karelz]

We have seen the interest. Last time we looked at it, there was difficulty in global vs. per session/handle settings - the latter is something we do not expose today.
I'm all for it, if we find a reasonable way to do it ...

[alnikola]

There is one issue that session and request handlers are created only when the first request is sent, meaning they cannot be set via regular properties. However, it seems quite easy to add callbacks to be invoked when session is created or on each requests where the user can access these handlers directly.

[alnikola]

@antonfirsov Please, take a look.

[antonfirsov]

We had a few discussions within the team realizing this feature isn't as trivial as it initially seemed.

TLDR: Currently we don't have a good way to validate an API for this feature.

More then the half of the options are bound to the request handle, and many of them have to be set and/or queried at arbitrary points of the request lifecycle. In #42592 I'm suggesting a solution to achieve this, but considering the fact that: (1) HttpClient implements a high level abstraction compared to the native WinHTTP API, (2) we don't (and can't) have a perfect understanding of all present and future options, there is a chance that we make a mistake with the design, and there will be a scenario left that can't be handled with this (or any other) proposal.

As part of the analysis I did a review on existing WinHttp options exposed through WinHttp handler properties in historical context:

WinHttpHandler Property	Native name	Session/Request	Introduced
AutomaticDecompression	WINHTTP_OPTION_DECOMPRESSION	Request (Creation)	initial commit
EnableMultipleHttp2Connections	WINHTTP_OPTION_DISABLE_STREAM_QUEUE	Session	7/13/2020
MaxAutomaticRedirections	WINHTTP_OPTION_MAX_HTTP_AUTOMATIC_REDIRECTS	Request (Creation)	initial commit
MaxConnectionsPerServer	WINHTTP_OPTION_MAX_CONNS_PER_SERVER	Session	initial commit
MaxResponseDrainSize	WINHTTP_OPTION_MAX_RESPONSE_DRAIN_SIZE	Request (Creation)	initial commit
MaxResponseHeadersLength	WINHTTP_OPTION_MAX_RESPONSE_HEADER_SIZE	Request (Creation)	initial commit
ReceiveDataTimeout	WINHTTP_OPTION_RECEIVE_TIMEOUT	Request (Sent)	initial commit
SslProtocols	WINHTTP_OPTION_SECURE_PROTOCOLS	Session	initial commit
No property, always enabled for secure HTTP2	WINHTTP_OPTION_ENABLE_HTTP2_PLUS_CLIENT_CERT	Request (Sending)	3/19/2020

Judging only by this data it is questionable whetherer this is indeed a critical feature. If there are not enough new user requests justifying the non-trivial design work we need to do to finish this feature, we'll probably put this on hold.

[geoffkizer]

Given the amount of work this would take, I think we should hold off doing anything here until we have clear customer requests for this.