HTTP 503-Service nicht verfügbar ist, wenn Sie versuchen zu navigieren signalr/hubs
Ich habe ein windows-hosted-SignalR-hub erstellt, in VS2012:
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.UseCors(CorsOptions.AllowAll);
app.MapSignalR();
}
}
public static class SignalR
{
public static void Start()
{
const string url = "http://*:8080";
WebApp.Start<Startup>(url);
}
}
public class Broadcaster : Hub
{
public void SendDownloadResult(bool result, string device, string description, string connectionId, string task)
{
var context = GlobalHost.ConnectionManager.GetHubContext<Broadcaster>();
context.Clients.Client(connectionId).sendDownloadResult(result, device, description, task);
}
}
Habe ich bereitgestellt, diese windows-service auf 3 verschiedenen PCs, es funktioniert gut auf beiden PCs, aber auf der anderen, bekomme ich HTTP 503-Service nicht verfügbar ist, wenn ich versuche, Sie zu durchsuchen http://localhost:8080/signalr/hubs
Keine Ausnahme geworfen, wenn der code ausgeführt wird, auf allen 3 PCs.
Habe ich überprüft IIS-Funktionen hinzufügen/entfernen von windows-Funktionen, Sie sind alle die gleichen.
Was bin ich?
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich war in der Lage reproduzieren diese lokal mit dem folgenden setup:
http://localhost:8080/
WebApp.Start<Startup>("http://*:8080")
http://localhost:8080/
Was passiert ist, dass Http.Sys akzeptiert die eingehende Anforderung, untersucht der host-header, beschließt, dass es eine Reservierung für localhost:8080 ein, aber merkt, dass keine Anwendung lauscht auf localhost:8080, nur *:8080. Http.Sys dann gibt die 503.
Lösungen:
WebApp.Start<Startup>("http://+:8080")
netsh http delete urlacl url=http://localhost:8080/
von einer administrator-Eingabeaufforderung sollte den trick tun.Ich hatte auch gleiche Problem. Ich behoben, indem Sie
ZU
Ich habe auch erkannt, dass in einem der PCs, den port 8080 im Einsatz war.
Ändern des Ports von
zu
löste das Problem
*
When the host element of a UrlPrefix consists of a single plus sign (+), the UrlPrefix matches all possible host names in the context of its scheme, port and relativeURI elements, and falls into the strong wildcard category.
When an asterisk (*) appears as the host element, then the UrlPrefix falls into the weak wildcard category. This kind of UrlPrefix matches any host name associated with the specified scheme, port and relativeURI that has not already been matched by a strong-wildcard