34

Ich habe einige RESTful-Dienste, die in einem reinen WCF-Kontext ausgeführt werden (d. H. Die ASP.NET-Kompatibilität ist nicht aktiviert, und daher ist kein HttpContext.Current-Objekt verfügbar).Was ist das WCF-Äquivalent von HttpContext.Current.Request.RawUrl?

Die URLs auf die Dienste werden zu Beginn des Antrags neu geschrieben ein mit IHttpModule (die an diesem Punkt eine haben HttpContext und schreibt es HttpContext.Current.RewritePath verwenden) aus der URL, um loszuwerden, Dinge wie die .svc Erweiterung.

Ich muss jedoch auf die ursprüngliche URL zugreifen, die von innerhalb der WCF-Infrastruktur angefordert wurde. Gibt es eine Entsprechung zu HttpContext.Current.Request.RawUrl auf den OperationContext oder WebOperationContext Klassen überall? Wenn Sie WebOperationContext.Current.IncomingRequest.UriTemplateMatch.RequestUri verwenden, wird die neu geschriebene URL zurückgegeben und nicht die ursprüngliche URL.

Antwort

40

Sie können den Endpunkt zur Zeit gezielt und Uri für sie, indem Sie erhalten:

OperationContext.Current.RequestContext.RequestMessage.Headers.To 

die ich denke, dasselbe ist wie:

OperationContext.Current.IncomingMessageHeaders.To 

Dies ist ein System.Uri Objekt, und ich glaube, Sie können nur die OriginalString oder PathAndQuery, oder was auch immer Sie Teile davon wollen.

2

versuchen, etwas wie folgt aus:

OperationContext.Current.Channel.LocalAddress.Uri.AbsoluteUri 
+0

Gute Antwort nach dem Titel der Frage (Sprich mit Google-Suche Perspektive) – Sami

+0

ich versuchte System.ServiceModel.Web.WebOperationContext.Current.IncomingRequest.UriTemplateMatch.RequestUri, OperationContext.Current.RequestContext.RequestMessage.Headers.To und OperationContext.Current.IncomingMessageHeaders.To, die einzige das funktioniert OperationContext.Current.Channel.LocalAddress.Uri – rob

1

ich gefunden habe, dass

mit
OperationContext.Current.RequestContext.RequestMessage.Headers.To 

meisten der Zeit arbeitet, aber nicht für meine Anwendung. Es befindet sich hinter einem NLB (Network Load Balancer), der dazu führt, dass der ursprüngliche Eingabe-Hostname verloren geht. Aber der Eingabe-Host ist immer noch in einer Kopfzeile namens "Host", die überraschend schwer zu bekommen war. Es befindet sich unter:

System.ServiceModel.Web.WebOperationContext.Current.IncomingRequest.Headers["Host"] 

(die Header-Objekte bei System.ServiceModel.OperationContext.Current.IncomingMessageHeaders nicht wirklich alle Header aus dem Client)

+0

Guter Punkt. Beachten Sie auch dieses Problem mit 'UserHostAddress': http://stackoverflow.com/q/650357/266535 – styfle