Running multiple IServer's

[Tratcher]

The current web host builder is designed to only work with only one IServer. It even relies on the DI behavior of using the last one registered so IIS can dynamically replace kestrel. We've had a few requests for applications that want to run Kestrel + HttpSys for example, to take advantage of their different capabilities. They don't want to start two processes or two hosts, they want to share a DI container, host infrastructure, and app pipeline.

From a pipeline perspective this should be fine, requests are processed one HttpContext at a time so there shouldn't be any cross contamination issues between the servers. The issues are mostly around setup.

Challenges:
A) Activation: how do you configure the host to create and start multiple servers? Could IIS be supported as one of those servers, or just Kestrel and HttpSys? Could you have multiple instances of one kind of server like Kestrel?
B) Configuration: how do you configure the bindings for those servers? They'd both try to consume the shared ASPNETCORE_URLS config. Luckily each server has its own programmatic config API.
C) IServerAddresses: This advertises the bindings for the server to the application. The servers would have to avoid stomping on eachother updating this.
D) What middleware make assumptions about working with a single server?

• Negotiate auth:

  aspnetcore/src/Security/Authentication/Negotiate/src/PostConfigureNegotiateOptions.cs

  Lines 29 to 56 in 8dedfde

  	public PostConfigureNegotiateOptions(IEnumerable<IServerIntegratedAuth> serverAuthServices, ILogger<NegotiateHandler> logger)
  	{
  	_serverAuth = serverAuthServices.LastOrDefault();
  	_logger = logger;
  	}
  	/// <summary>
  	/// Invoked to post configure a TOptions instance.
  	/// </summary>
  	/// <param name="name">The name of the options instance being configured.</param>
  	/// <param name="options">The options instance to configure.</param>
  	public void PostConfigure(string name, NegotiateOptions options)
  	{
  	// If the server supports integrated authentication...
  	if (_serverAuth != null)
  	{
  	// And it's on...
  	if (_serverAuth.IsEnabled)
  	{
  	// Forward to the server if something else wasn't already configured.
  	if (options.ForwardDefault == null)
  	{
  	Debug.Assert(_serverAuth.AuthenticationScheme != null);
  	options.ForwardDefault = _serverAuth.AuthenticationScheme;
  	options.DeferToServer = true;
  	_logger.Deferring();
  	}
  	}

• HttpsRedirection: Enhance HTTPS redirect middleware for multi-hostname scenarios #21291
• IIS out-of-proc middleware:
  

  aspnetcore/src/Servers/IIS/IISIntegration/src/IISMiddleware.cs

  Lines 120 to 125 in 8dedfde

  	if (!string.Equals(_pairingToken, httpContext.Request.Headers[MSAspNetCoreToken], StringComparison.Ordinal))
  	{
  	_logger.LogError($"'{MSAspNetCoreToken}' does not match the expected pairing token '{_pairingToken}', request rejected.");
  	httpContext.Response.StatusCode = StatusCodes.Status400BadRequest;
  	return;
  	}

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[JKamsker]

@Tratcher did you find a way to solve this issue?

[mconnew]

This scenario is important for CoreWCF as we need to use Kestrel alongside other IServer implementations. The primary one having one endpoint listening on HTTP while hosted in IIS, and one or more endpoints using Kestrel to listen on NetTcp, UnixDomainSocket, and/or NetNamedPipe. Currently we construct Kestrel using ActivatorUtilities.CreateInstance when the primary IServer isn't already Kestrel. As we're adding UnixDomainSocket support, we'll also do this when the primary IServer is Kestrel, but using TCP sockets.

[slaneyrw]

Another use-case is to attach to Azure Relay (Microsoft.Azure.Relay.AspNetCore) and route incoming requests from the hybrid connection along side Kestrel/HTTPSys