大家好,我在使用 Visual Studio 2008 (Cassini) 的内置 Web 服务器上本地测试 ASP.NET 应用程序时似乎发现了差异。
我已在本地计算机上设置了一个主机将 dev.testhost.com 与 127.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
发布评论
评论(3)
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.
这是 w3 规范 的说法与Microsoft Uri.Host 属性应该是什么包含。该命名并不意味着 MS 试图提供相同的功能。包含端口号的函数是 Uri.Authority。
通过您发布的更新,您仍然面临同样的问题,只是检查它的不同方面。 Uri.Host 属性 不是显式或隐式声明执行与 w3 规范中定义的标头相同的功能。以下是来自 Uri.Host MSDN 页面的一些详细引用:
不能保证这与标头中的内容匹配,只是它以某种形式表示主机名。
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:
There's no guarantee that this will match what is in the headers, just that it represents the host name in some form.
Request.Headers["host"]
是从连接到服务器的应用程序接收到的值,而另一个值是服务器尝试获取域名时获取的值。浏览器在请求中使用输入的域名,因为该域名用于虚拟域。服务器报告服务器首选项中设置的一组,或者它找到的第一个组。
编辑:查看卡西尼的代码以查看它是否使用某些特定设置,我注意到以下代码:
解释似乎是卡西尼明确引用了本地主机,并且不尝试使反向 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:
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;
.