为什么 Request["host"] == "dev.testhost.com:1234"而 Request.Url.Host == "localhost"

发布于 2024-08-15 18:51:52 字数 683 浏览 7 评论 0 原文

大家好,我在使用 Visual Studio 2008 (Cassini) 的内置 Web 服务器上本地测试 ASP.NET 应用程序时似乎发现了差异。

我已在本地计算机上设置了一个主机将 dev.testhost.com127.0.0.1 关联,因为我有一个应用程序需要根据用于调用它的主机标头来更改其外观。

但是,当我使用 http://dev.testhost.com:1234/index.aspx 请求测试应用程序时,Request.Url.Host 的值始终为 <代码>“本地主机”。而 Request.Headers["host"] 的值是 "dev.testhost.com:1234" (正如我所期望的两者是)。

我不担心第二个值包含端口号,但我很困惑为什么主机名完全不同!有谁知道这是一个已知问题还是设计使然?还是我是个白痴?!

我宁愿使用 Request.Url.Host,因为这样可以避免在测试时删除端口号... - 由于可能引起混乱而被删除! - 萨姆

Hi all, I seem to have found a discrepancy when testing ASP.NET applications locally on the built-in web server with Visual Studio 2008 (Cassini).

I've set up a host on my local machine associating dev.testhost.com with 127.0.0.1, since I have an application that needs to change its appearance depending on the host header used to call it.

However, when I request my test application using http://dev.testhost.com:1234/index.aspx, the value of Request.Url.Host is always "localhost". Whereas the value of Request.Headers["host"] is "dev.testhost.com:1234" (as I would expect them both to be).

I'm NOT concerned that the second value includes the port number, but I am mighty confused as to why the HOST NAMES are completely different! Does anyone know if this is a known issue, or by design? Or am I being an idiot?!

I'd rather use Request.Url.Host, since that avoids having to strip out the port number when testing... - Removed due to possibly causing confusion! - Sam

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

半透明的墙 2024-08-22 18:51:53

Request.Headers["host"] 是浏览器的 http 标头中指定的主机。 (例如,如果您使用 Fiddler 或 HttpWatch 检查流量,您会看到以下内容)

但是,ASP.NET 将此信息(以及其他请求信息)加载到 System.Uri 实例中,该实例会解析请求串入其组成部分。在这种情况下,“主机”实际上是指原始请求的主机部分(例如,tcp 端口位于端口中)属性。

这个 System.Uri 类是一个非常有用的帮助器类,它消除了将请求分成多个部分的所有痛苦,而“Host:”(以及就此而言的“GET”)来自http 标头只是原始请求数据。

尽管它们具有相同的名称,但它们并不意味着是同一件事。

The Request.Headers["host"] is the host as specified in the http header from the browser. (e.g. this is what you'd see if you examined the traffic with Fiddler or HttpWatch)

However, ASP.NET loasds this (and other request info) into a System.Uri instance, which parses the request string into its constituent parts. In this case, "Host" refers to literally the host machine part of the original request (e.g. with the tcp port being in the Port) property.

This System.Uri class is a very useful helper class that takes all the pain out of splitting your request into it's parts, whereas the "Host:" (and for that matter the "GET") from the http header are just raw request data.

Although they both have the same name, they are not meant to be the same thing.

最笨的告白 2024-08-22 18:51:53

这是 w3 规范 的说法与Microsoft Uri.Host 属性应该是什么包含。该命名并不意味着 MS 试图提供相同的功能。包含端口号的函数是 Uri.Authority

通过您发布的更新,您仍然面临同样的问题,只是检查它的不同方面。 Uri.Host 属性 不是显式或隐式声明执行与 w3 规范中定义的标头相同的功能。以下是来自 Uri.Host MSDN 页面的一些详细引用:

Uri.Host 属性
获取该实例的主机组件。

财产价值

类型:System.String

包含主机名的字符串。这通常是服务器的 DNS 主机名或 IP 地址。

不能保证这与标头中的内容匹配,只是它以某种形式表示主机名。

It's a matter of what the w3 specs say versus what the Microsoft Uri.Host property is supposed to contain. The naming does not imply an attempt by MS to provide identical functionality. The function that does include port numbers is Uri.Authority.

With the update you posted, you're still facing the same problem, just examining a different aspect of it. The Uri.Host property is not explicity or implicity stated to perform the same function as the headers that are defined in the w3 specs. In long form, here are some quotes from the Uri.Host MSDN page:

Uri.Host Property
Gets the host component of this instance.

Property Value

Type: System.String

A String that contains the host name. This is usually the DNS host name or IP address of the server.

There's no guarantee that this will match what is in the headers, just that it represents the host name in some form.

来日方长 2024-08-22 18:51:52

Request.Headers["host"] 是从连接到服务器的应用程序接收到的值,而另一个值是服务器尝试获取域名时获取的值。

浏览器在请求中使用输入的域名,因为该域名用于虚拟域。服务器报告服务器首选项中设置的一组,或者它找到的第一个组。

编辑:查看卡西尼的代码以查看它是否使用某些特定设置,我注意到以下代码:

public string RootUrl {
  get {
    if (_port != 80) {
      return "http://localhost:" + _port + _virtualPath;
    }
    else {
      return "http://localhost" + _virtualPath;
    }
  }
}

//
// Socket listening
//

public void Start() {
  try {
    _socket = CreateSocketBindAndListen(AddressFamily.InterNetwork, IPAddress.Loopback, _port);
  }
  catch {
    _socket = CreateSocketBindAndListen(AddressFamily.InterNetworkV6, IPAddress.IPv6Loopback, _port);
  }
  // …
}

解释似乎是卡西尼明确引用了本地主机,并且不尝试使反向 DNS 查找。不同的是,它不会使用 return "http://localhost" + _virtualPath; 。

Request.Headers["host"] is the value received from the application that connects to the server, while the other value is the one the server gets when it tries to get the domain name.

The browser uses in the request the domain name entered because that is used in the case of virtual domains. The server reports the one set in the server preferences, or the first one it finds.

EDIT: Looking at the code of Cassini to see if it uses some particular settings, I noticed the following code:

public string RootUrl {
  get {
    if (_port != 80) {
      return "http://localhost:" + _port + _virtualPath;
    }
    else {
      return "http://localhost" + _virtualPath;
    }
  }
}

//
// Socket listening
//

public void Start() {
  try {
    _socket = CreateSocketBindAndListen(AddressFamily.InterNetwork, IPAddress.Loopback, _port);
  }
  catch {
    _socket = CreateSocketBindAndListen(AddressFamily.InterNetworkV6, IPAddress.IPv6Loopback, _port);
  }
  // …
}

The explanation seems to be that Cassini makes explicit reference to localhost, and doesn't try to make a reverse DNS lookup. Differently, it would not use return "http://localhost" + _virtualPath;.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文