HttpContext.Current.Request.RawUrl 的 WCF 等效项是什么？
我有一些在纯 WCF 上下文中运行的 RESTful 服务（即未启用 ASP.NET 兼容性，因此没有可用的 HttpContext.Current 对象）。
服务的 URL 在请求开始时使用 IHttpModule 重写（此时它确实有一个 HttpContext 并使用 HttpContext.Current 重写它。 RewritePath）以删除 URL 中的 .svc 扩展名等内容。
但是，我需要访问从 WCF 基础结构中请求的原始 URL。 任何地方的 OperationContext 或 WebOperationContext 类上是否存在与 HttpContext.Current.Request.RawUrl 等效的内容？ 使用 WebOperationContext.Current.IncomingRequest.UriTemplateMatch.RequestUri 返回重写的 URL，而不是原始 URL。
I've got some RESTful services running in a pure WCF context (i.e. ASP.NET compatibility is not enabled, and thus there is no HttpContext.Current object available).
The URLs to the services are rewritten at the start of the request using an IHttpModule (which at that point does have an HttpContext and rewrites it using HttpContext.Current.RewritePath) to get rid of things like the .svc extension from the URL.
However, I need to access the original URL that was requested from within the WCF infrastructure. Is there an equivalent to HttpContext.Current.Request.RawUrl on the OperationContext or WebOperationContext classes anywhere? Using WebOperationContext.Current.IncomingRequest.UriTemplateMatch.RequestUri returns the rewritten URL not the original one.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以通过执行以下操作来获取当前目标端点及其 Uri：
我认为这与以下操作相同：
This is a System.Uri object, and I believe you can just get the
OriginalString或PathAndQuery，或者您想要从中获得的任何部分。You can get the endpoint currently targeted and the Uri for it by doing:
which I think is the same thing as:
This is a
System.Uriobject, and I believe you can just get theOriginalStringorPathAndQuery, or whatever parts you want from it.尝试这样的事情：
try something like this:
我发现使用
在大多数情况下都有效，但对于我的应用程序却不起作用。 它位于 NLB（网络负载均衡器）后面，这导致它丢失原始输入主机名。 但是输入主机仍然位于名为“Host”的标头中，这令人惊讶地难以获取。 它位于：（
System.ServiceModel.OperationContext.Current.IncomingMessageHeaders 处的标头对象并未真正拥有来自客户端的所有标头）
I have found that using
works most of the time, but did not for my application. It is behind an NLB (Network Load Balancer), which causes it to lose the original input host name. But the input host is still in a header named "Host", which was surprisingly hard to get at. It is located at:
(the header objects at System.ServiceModel.OperationContext.Current.IncomingMessageHeaders did not truly have all the headers from the client)