Closed chandimar001 closed 5 years ago
I'm not aware of any limitation here, you'll have to ask service fabric. The IIS limitation is specific to how IIS verifies the right process Id opened the assinged port.
I checked with the service fabric team and found a way around this.
WebListener works (for me) only when I register it with a wild card URL. https://github.com/aspnet/Hosting/issues/749
Service Fabric reverse proxy needs the FQDN to forward the request to. It won't work with a wild card,
I updated my code so that UseUrls() uses the wild card path, but OpenAsync() returns the FQDN so that SF reverse proxy can communicate with it. This fixes my issue.
public Task<string> OpenAsync(CancellationToken cancellationToken)
{
var endpoint = FabricRuntime.GetActivationContext().GetEndpoint(this.endpointName);
// WebListener needs to run on a wildcard url like http://+:5000
string serverUrl = $"{endpoint.Protocol}://+:{endpoint.Port}";
// Service Fabric reverse proxy needs to listen to a fully qualified url like http://localhost:5000
string sfserverUrl = $"{endpoint.Protocol}://{FabricRuntime.GetNodeContext().IPAddressOrFQDN}:{endpoint.Port}";
this.webHost = this.webHostBuilder
.UseWebListener(options =>
{
options.ListenerSettings.Authentication.Schemes = AuthenticationSchemes.None;
options.ListenerSettings.Authentication.AllowAnonymous = true;
})
.UseContentRoot(Directory.GetCurrentDirectory())
.UseStartup<Startup>()
.UseUrls(serverUrl)
.Build();
this.webHost.Start();
return Task.FromResult(sfserverUrl);
}
I am in the process of migrating our service from Kestrel to WebListener. Our service is in Service Fabric and the requests are routed to the service through the Service Fabric reverse proxy. Kestrel is configured to run on port 5000. I can successfully hit my service with both of these URLs:
I now have WebListener successfully listening on port 5000. http://localhost:5000/blah works as expected. However, the reverse proxy route fails (returns a 500) - http://localhost:19081/{servicename}/blah.
I know that WebListener cannot be used with IIS or IIS Express and am wondering if those limitations are at the heart of this, or if there is some routing or config that I am overlooking.
I understand that routing the request through the SF reverse proxy is counter productive, but it will make the deployment steps for the migration easier.
There could also be some network security settings I might be overlooking, but want to know if this a supported scenario or not.