我从以下网页开始:
http://127.0.0.1:84/Administration/Accounts/Home
然后我选择了一个链接,它需要我:
http://127.0.0.1:84/Administration/Accounts/ShowSummary?ds=0001
在ShowSummary剃刀页面的开头,我查看
Request.Url http://127.0.0.1:86/Administration/Accounts/ShowSummary?ds=0001}
Request.Url.Authority "127.0.0.1:86"
Request.UrlReferrer - {http://127.0.0.1:84/Administration/Accounts/Home}
每次尝试时,它总是报告端口86而不是端口84.这对我来说很重要,因为我存储了URL。有谁知道它为什么显示不同的端口?正确的端口应为84但Url和Url.Authority报告86
答案 0 :(得分:7)
是的,我很清楚为什么会这样。首先,请让我在Windows Azure上分享一个细节,这样您就能够了解问题的本质。
在Windows Azure环境中部署云服务时,它位于负载均衡器(或LB)后面的虚拟机(所谓的实例)中。定义Input Endpoint时,指示您希望将特定TCP端口路由到您的实例的Windows Azure基础结构。因此,LB在其防火墙端口80上打开,并将来自该端口的流量路由到您的VM。您的VM上的端口80也会在防火墙中打开。但是有两个不同的主机 - LB和VM,两者都可以有端口80。
为了在本地正确模拟所有行为,Windows Azure Emulator在本地IIS中创建一个Web站点并将其绑定到某个端口(在您的情况下为86!)。然后它“模拟”LB并打开端口84(对于模拟的LB)。之所以如此,是因为您的角色中可能定义了多个实例。本地模拟器为您定义的每个实例和任何实例创建一个单独的网站。每个实例都有自己的指定端口(86,87,88等...),而原始(在你的情况下为84)只有一个 - 用于模拟LB.
这就是你的Request.Url.Authority是端口86的原因 - 因为你的本地站点绑定到端口86.这就是为什么URLReferer是端口84 - 因为实际请求来自模拟的负载均衡器,它适用于端口84。
我希望您猜测在真实的Azure环境中不会发生这种情况,因为两个端口都是80。
当人们处理端口时,我通常建议使用可以从以下位置获得的IPEndpoint实例:
RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["HttpIn"].IPEndpoint
但你的情况有点不同。您正在记录完整的URL。我不知道你想要实现什么,但这里有一些提示,你可能认为有价值:
希望这有帮助。
答案 1 :(得分:3)
如果在本地Azure环境中工作时某些人仍然需要获得绝对的Uri,解决方案是:
var absoluteUriString = string.Format(
"{0}://{1}{2}",
Request.Url.Scheme, // protocol
Request.Headers["Host"], // needed host with correct port number
Request.RawUrl); // right part of the uri string
var absoluteUri = new Uri(absoluteUriString);
答案 2 :(得分:0)
您知道在关闭上一个会话后如何快速重新启动网站,那么它会为您分配下一个端口号吗? 84 - > 85 - > 86
在这种情况下,我有时会观察旧端口号继续工作,即使他们的调试会话已停止。我从来没有真正研究过它,也许这只是我脑中的一个大脑错误,但也许这就是正在发生的事情。您可以直接尝试端口86,看看是否有效。