HttpContext.Current.Request.Url.Host 的起源在哪里？
为什么 HttpContext.Current.Request.Url.Host 返回的 URL 与 Web 浏览器中使用的 URL 不同？例如，在浏览器中输入“www.someurl.com”时，HttpContext.Current.Request.Url.Host 变量等于“www.someotherurl.com”。
Why does HttpContext.Current.Request.Url.Host return a different URL than the URL used in the Web browser? For example, when entering "www.someurl.com" in the browser, the HttpContext.Current.Request.Url.Host variable is equal to "www.someotherurl.com".
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
HttpContext.Current.Request.Url.Host是 ASP.net 应用程序接收的 Host 标头的内容。 （参见http://www.w3.org/Protocols/rfc2616/rfc2616- sec14.html 了解有关 HTTP 标头（例如Host）的更多信息。通常，ASP.NET 看到的标头与浏览器发送的
Host标头相同。但是，如果软件或硬件位于浏览器和 ASP.net 代码之间并重写Host标头，它们可能会不匹配。例如，像 GoDaddy 这样的大型预算托管商就这样做，这样他们就可以在单个 IIS 网站上支持多个顶级域，即使他们的托管计划更便宜。 GoDaddy 不会创建单独的 IIS 网站（这会增加服务器负载并因此增加成本），而是重新映射对 http://secondsite.com 的请求/ 到“主”托管站点上的虚拟目录，例如 http://firstsite.com/secondsite< /a>）。他们将更改 Host: 标头以及 URL。
顺便说一句，您可以通过转储 您的应用正在接收的 HTTP 请求标头。
无论如何，如果您想弄清楚谁在更改 Host 标头，请从托管您的 Web 应用程序的人员（或负责负载均衡器和/或反向代理的团队）开始，因为他们可能是负责的人用于重写您的主机标头。
HttpContext.Current.Request.Url.Hostis the contents of the Host header that the ASP.net application receives. (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html for more info about HTTP headers likeHost).Usually the header that ASP.NET sees is identical to the
Hostheader sent by the browser. However, it's possible they won't match if software or hardware is sitting in between the browser and your ASP.net code and is rewriting theHostheader.For example, large-scale budget hosters like GoDaddy do this so they can support multiple top-level domains on a single IIS website, even on their cheaper hosting plans. Instead of creating a separate IIS website (which adds to server load and hence cost), GoDaddy remaps requests for http://secondsite.com/ to a virtual directory on your "main" hosted site, e.g. http://firstsite.com/secondsite). They will change both the Host: header as well as the URL.
BTW, you can easily verify that this is what's happening by dumping the contents of HTTP Request Headers that your app is receiving.
Anyway, if you want to figure out who is changing the Host header, start with the people who host your web app (or the team which is responsible for your load balancer and/or reverse proxy), since they're likely the ones responsible for rewriting your Host header.