Productize ManagedHandler for HttpClient

[stephentoub]

We've checked in a prototype C# implementation of an HttpClientHandler. But there's lots of work left to do on it.

• Get all existing tests passing.
• Add lots of additional protocol-related tests
• Add support for digest auth
• Add support for NTLM auth
• Add support for Negotiate auth
• Add better connection pooling support
• Add HTTP/2 support
• Add support for environment variables recognized by existing handlers
• Lots of fit and finish
• Perf
• Perf
• Perf
• Perf
• ... you get the idea
• Determine if/how it should be shipped initially

[stephentoub]

cc: @geoffkizer, @Priya91

[clairernovotny]

One thing I would like to see/ensure is that the HttpClient instance can play nicely with external diagnostic tools like Fiddler and Visual Studio's network debug trace diagnostics. The current .NET Core one on Windows requires hoops like changing the hostname called to localhost.fiddler in order to see the traces.

[stephentoub]

Thanks, @onovotny. Do you know what it is about WinHttp or WinHttpHandler that causes that not to be the case? Is it something that can be fixed in WinHttpHandler as well, or is it specific to the lower-level?

[clairernovotny]

I'm not 100% sure, but I believe it doesn't respect the default proxy setting if the hostname is localhost

[clairernovotny]

http://docs.telerik.com/fiddler/configure-fiddler/tasks/MonitorLocalTraffic
http://docs.telerik.com/fiddler/observe-traffic/troubleshooting/notraffictolocalhost

[karelz]

@onovotny this is the Networking stack proposal I sent to bunch of you couple of months ago. I didn't get time to publish it publicly on dotnet/designs repo, something I plan to finally fix this weekend.

We can provide additional info bout our current execution plan, but the high-level idea is still the same ...

[karelz]

Moving to Future as some parts will likely not make it into 2.1. We are still debating which parts. It heavily depends on funding available and how much we will have to invest in other Networking asks (ALPN, Faster SslStream and Sockets perf on Linux for Kestrel)

[Matthias247]

Regarding

• Add HTTP/2 support

As some of you might be aware of I have implemented a fully managed HTTP/2 library, which allows clients and servers to be built on top of it. All basic client and server features should be working and it has a really big test coverage. Secure HTTP/2 (h2) and the associated browser-support should be working out of the box as soon as #15813 is available.

You might want to check out if you can use it (or parts of it) for your work. Unfortunately I currently don't have time to investigate how exactly your HTTP/1 implementation works and what the integration points are. But if you have questions or issues around my library just ask. You basically should need some architecture like:

+--------------+     +---------------+ 1      1 +-----------------+
| [TLS] Socket |--+--| HTTP/1 parser |----------| Request/Reponse |
+--------------+  |  +---------------+          | Abstraction     |
                  | or                          +-----------------+
                  |  +-------------------+
                  +--| HTTP/2 connection | 1  n +-----------------+
                     | state machine     |------| Request/Reponse |
                     +-------------------+      | Abstraction     |
                                                +-----------------+

which means the common parts between HTTP/1 and HTTP/2 are only the request/response abstractions and everything which is built on top of it (auth, cookies, content-enconding, etc.). But pretty much everything below it is completely different.

[karelz]

As promised (months ago :(), I published Networking Technical roadmap to gather further feedback from community. It describes reasoning behind our investments here and in future.

[robertmclaws]

Will this implementation fix the issues with HttpClient? Namely https://aspnetmonsters.com/2016/08/2016-08-27-httpclientwrong/

Thanks!

[stephentoub]

@robertmclaws, what change are you hoping for? HttpClient's design optimizes for having fewer instances that are shared; that won't change by changing the implementation of HttpClientHandler. If you're hoping to see some additional API surface area, please open separate issue(s) with proposals for that. Thanks.

[stephentoub]

I've opened a bunch of individual issues for known work associated with the managed handler, so I'm going to close this overall issue now.