【问题标题】:Why does Request["host"] == "dev.testhost.com:1234" whereas Request.Url.Host == "localhost"为什么 Request["host"] == "dev.testhost.com:1234" 而 Request.Url.Host == "localhost"
【发布时间】:2010-12-28 19:56:10
【问题描述】:

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

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

但是,当我使用http://dev.testhost.com:1234/index.aspx 请求我的测试应用程序时,Request.Url.Host 的值始终为"localhost"。而Request.Headers["host"] 的值是"dev.testhost.com:1234"(正如我所期望的那样both)。

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

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

【问题讨论】:

  • 从 MSDN 文档看来,Request.Url 应该与发送到服务器的请求有关。引用msdn.microsoft.com/en-us/library/system.web.httprequest.aspx ... > HttpRequest 类 > 使 ASP.NET 能够读取客户端在 Web 请求期间发送的 HTTP 值。这不是它在 Cassini 中运行时似乎在做的事情......感谢迄今为止的答案,但我真的不相信有任何充分的理由为同一个请求对象报告不同的主机名......

标签: c# asp.net visual-studio debugging cassini


【解决方案1】:

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

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

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

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);
  }
  // …
}

解释似乎是 Cassini 明确引用了 localhost,并没有尝试进行反向 DNS 查找。不同的是,它不会使用return "http://localhost" + _virtualPath;

【讨论】:

  • 嗯,服务器的IP地址是127.0.0.1。这有 2 个主机映射到 c:\windows\system32\drivers\etc\hosts:localhostdev.testhost.com 但是,当我输入 'dev.testhost .com' HttpContect.Current.Request.Url.Host 的值是'localhost'?在生产服务器上,它将是我输入的任何内容。为什么本地测试服务器(Cassini)与实时服务器不同?
  • 主机是按什么顺序定义的?可能顺序会影响服务器报告的顺序。
  • 我只是尝试更改主机的顺序,这没有任何区别!不过是个好主意;)我认为如果这行得通,那将是令人惊讶的,因为如果要始终如一地工作,那可能需要进行反向 DNS 查找,我怀疑他们是否会将其放入一个听起来很简单的属性中……我怀疑那里是 Cassini 中的一个错误,它导致了这种差异!
  • 您确定没有任何设置可以更改从服务器返回的域名吗?
  • 真的,我很困惑为什么HttpRequest 类的property Url 与@987654327 的HTTP 请求的URL 不匹配@object 旨在表示...如果它进行某种服务器询问以发现与服务器关联的其他主机名,我希望它是某个其他对象的属性,而不是 HttpRequest 实例...
【解决方案2】:

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

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

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

虽然它们都具有相同的名称,但它们并不意味着相同。

【讨论】:

  • 感谢您的回答,但我想知道的是,“拆分”dev.testhost.com:1234 会如何导致完全丢失“dev.testhost.com”部分,并将其替换为“localhost” '?我的问题不是关于 Uri 或 UriBuilder 类,我很理解这些;)另外,端口号根本不是问题。我在问题的第 3 段中添加了 emphasis,也许这样会更清楚?再次感谢;)
  • 嗯 - 你已经说过你已经将 dev.testhost.com 与 IP 地址 127.0.0.1 相关联。但是,此 IP 地址始终映射到 localhost(根据定义 - 它是环回地址) - 因此 127.0.0.1 上的任何名称查找都将映射到 localhost。当您说“将 dev.testhost.com 与 127.0.0.1 关联”时,您是如何做到的?您是编辑了 hosts 文件,还是以其他方式进行了编辑?
  • 我在 hosts 文件中添加了该条目。请在下面查看 kiamlaluno 的答案...看起来这是卡西尼号特有的问题...
【解决方案3】:

这是w3 specs 所说的内容与Microsoft Uri.Host 属性应该包含的内容的问题。命名并不意味着 MS 试图提供相同的功能。包含端口号的函数是Uri.Authority

随着您发布的更新,您仍然面临同样的问题,只是检查了它的不同方面。 Uri.Host property 没有明确或暗示执行与 w3 规范中定义的标头相同的功能。以下是 Uri.Host MSDN 页面的一些引文:

Uri.Host 属性
获取此实例的宿主组件。

物业价值

类型:System.String

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

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

【讨论】:

  • 感谢您的尝试,但您误读了这个问题,我现在已经强调说 我不担心第二个值包括端口号
  • 我的回答仍然适用 - 我已经扩展它以使与您的更新的相关性更加明显,但您的基本问题是假设 System.Uri 对象应该直接与 http 标头匹配您正在使用 Request.Headers 检索。
  • System.Uri 类的对象通常只代表 URI,我的问题是关于 System.Uri 类的 Request.Url instance,从 aspx 页面访问由于对特定 URL 的请求而呈现的。如果属性Request.UriRequest 的网址不匹配,那么它的意义何在?为了澄清,您可以调用“Request.Url.ToString()”,它仍然报告http://localhost:1234/Default.aspx,而请求是针对http://dev.testhost.com:1234/Default.aspx...
  • 简单地说,Request.Url 根据定义是经过处理的,而不是原始的。在Request.Headers 中找到的回复不是。不应期望已处理的 Url.Host 与从 Request.Headers["host"] 获得的原始输出匹配,但应期望代表相同的 URI。这可能会让您感到惊讶,但这不是问题。
  • 但是localhost:1234dev.testhost.com:1234 不是同一个URI,你可以看到它们是不同的;)
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-09-28
  • 2012-08-22
  • 1970-01-01
  • 2015-01-30
  • 1970-01-01
相关资源
最近更新 更多