We currently only implement Dispose and call Wait() on the host StopAsync() within Dispose.

Ideally we want to avoid this and simply implement IAsyncDisposable with IDisposable just being a fallback for it.

The only issue here is that currently the factory can be use as an xUnit fixture out of the box, but unfortunately I believe xUnit doesn't support IAsyncDisposable in addition to ID

Describe the bug

The current implementation of the authorization header parsing has (at least) the following issues:

• A value can't contain any commas
• A value can't start or end with a doublequote
• A value can't contain special characters
  • HTTP Headers only allow ASCII characters
  • There is no option to encode/decode the values (using base64 or urlencoding)
• When a value c

We can build much smaller Mono runtime for .NET Core purposes by simply removing code we don't need in this configuration. We did a few easy initial steps but we can go much further.

This list is not comprehensive but parts like

• Culture Data
• Any PAL related code
• Unused icalls

Remove logging line, or modify from ch.Info to ch.Trace:
https://github.com/dotnet/machinelearning/blob/5dbfd8acac0bf798957eea122f1413209cdf07dc/src/Microsoft.ML.Mkl.Components/SymSgdClassificationTrainer.cs#L813

For my text dataset, this logging line dumps ~100 pages of floats to my console. That level of verbosity is unneeded at the Info level.

I'd recommend just removing the loggin

Whenever I submit a GET request to the api/public/groups endpoint, the "collections" field for each group returns "None" on every group, even if they have access to collections. I can verify that the

The Job and Toolchain columns are redundant, Runtime is all we need:

I see this very often when our users are presenting BDN results at conferences|meetups etc

The Job column should remain visible when the user has set the Job id in explicit way.

/cc @stephentoub

Expected Behavior / New Feature

Support sticky sessions for ServiceDiscoveryProviders

Actual Behavior / Motivation for New Feature

When using websockets with ocelot in a distributed system, problem can arise since ocelot, as far as i know, doesn't support sticky sessions when working with service discovery providers.

The functionality could be great if it could work with both consul