2009-12-21 17 views
16

Hola a todos, parece haber encontrado una discrepancia al probar aplicaciones ASP.NET localmente en el servidor web incorporado con Visual Studio 2008 (Cassini).¿Por qué Request ["host"] == "dev.testhost.com:1234" mientras que Request.Url.Host == "localhost"

He creado una serie en mi máquina local asociando dev.testhost.com con 127.0.0.1, ya que tengo una aplicación que necesita para cambiar su apariencia dependiendo del encabezado de host utilizado para llamar eso.

Sin embargo, cuando solicito mi aplicación de prueba usando http://dev.testhost.com:1234/index.aspx, el valor de Request.Url.Host es siempre "localhost". Mientras que el valor de Request.Headers["host"] es "dev.testhost.com:1234" (como yo esperaría que sean ambos).

No me preocupa que el segundo valor incluye el número de puerto, pero yo soy poderoso confundido en cuanto a por qué los nombres de host son completamente diferentes! ¿Alguien sabe si esto es un problema conocido, o por diseño? ¿O estoy siendo un idiota?

prefiero usar Request.Url.Host, ya que evita tener que pelar hacia fuera el número de puerto al probar ... -Se ha eliminado debido a que puede causar confusión! - Sam

+0

De la documentación de MSDN en que parece que el Request.Url debe estar preocupado con la solicitud como se envía al servidor. Citando de http://msdn.microsoft.com/en-us/library/system.web.httprequest.aspx ... > ** HttpRequest Class ** > Permite a ASP.NET leer los valores HTTP enviados por un cliente durante una solicitud web. Que no es lo que parece estar haciendo cuando se ejecuta en Cassini ... Gracias por las respuestas hasta ahora, pero realmente no estoy convencido de que exista una buena razón para informar el nombre de host de manera diferente para la misma solicitud objeto ... –

Respuesta

9

Request.Headers["host"] es el valor recibido de la aplicación que se conecta al servidor, mientras que el otro valor es el que obtiene el servidor cuando intenta obtener el nombre de dominio.

El navegador usa en la solicitud el nombre de dominio ingresado porque se usa en el caso de dominios virtuales. El servidor informa el establecido en las preferencias del servidor, o el primero que encuentra.

EDIT: Si examina el código de Cassini para ver si se utiliza algunas configuraciones particular vi el siguiente código:

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

La explicación parece ser que Cassini hace referencia explícita a localhost, y no intenta realizar una búsqueda DNS inversa. De manera diferente, no usaría return "http://localhost" + _virtualPath;.

+0

Bueno, la dirección IP del servidor es 127.0.0.1. Esto tiene 2 hosts mapeados en c: \ windows \ system32 \ drivers \ etc \ hosts: ** localhost ** y ** dev.testhost.com ** Sin embargo, cuando escribo 'dev.testhost.com' el valor de 'HttpContect.Current.Request.Url.Host' es 'localhost'? En un servidor de producción, será lo que escribo. ¿Por qué el servidor de prueba local (Cassini) es diferente del servidor en vivo? –

+0

¿En qué orden se definen los hosts? Probablemente la orden influya en la informada por el servidor. – kiamlaluno

+0

¡Intenté cambiar el orden de los hosts y esto no hizo ninguna diferencia! Buena idea;) Creo que sería sorprendente si esto funcionara, ya que eso probablemente requeriría una búsqueda DNS inversa si fuera a funcionar de manera consistente, lo que dudo que pusieran en una propiedad de sonido simple ... sospecho que hay es un error en Cassini que causa esta discrepancia! –

1

Es una cuestión de lo que dice el w3 specs frente a lo que se supone que contiene la propiedad Microsoft Uri.Host. La denominación no implica un intento por parte de MS de proporcionar una funcionalidad idéntica. La función que incluye números de puerto es Uri.Authority.

Con la actualización que ha publicado, aún enfrenta el mismo problema, simplemente examinando un aspecto diferente de la misma. El Uri.Host property no es explícito o implícito establecido para realizar la misma función que los encabezados que están definidos en las especificaciones w3. En forma larga, aquí hay algunas citas de la página de MSDN: Uri.Host

Uri.Host Propiedad
Obtiene el componente de sistema principal de esta instancia.

Propiedad Valor

Tipo: System.String

una cadena que contiene el nombre de host. Este suele ser el nombre de host DNS o la dirección IP del servidor.

No hay garantía de que coincida con lo que está en los encabezados, solo que representa el nombre de host de alguna forma.

+0

Gracias por su intento, pero ha leído mal la pregunta, he añadido énfasis ahora en el bit que decía ** NO me preocupa que el segundo valor incluya el número de puerto ** –

+0

Mi la respuesta sigue siendo aplicable: la he ampliado para hacer que la correlación con su actualización sea más obvia, pero su problema básico es la suposición de que un objeto 'System.Uri' debe coincidir directamente con los encabezados http que está recuperando con' Request .Huederes'. – jball

+0

Los objetos de la clase 'System.Uri' solo representan URIs en general, mi pregunta es acerca de la instancia' Request.Url' ** de la clase 'System.Uri', como se accede desde una página aspx que se está renderizando debido a una solicitud de una URL en particular. ¿Cuál es el punto de la propiedad 'Request.Uri' si no coincide con la URL de' Request'? Para aclarar, puede llamar 'Request.Url.ToString()' y sigue notificando 'http: // localhost: 1234/Default.aspx' mientras que la solicitud era para' http://dev.testhost.com: 1234/Default.aspx' ... –

8

El Request.Headers["host"] es el host tal como se especifica en la cabecera HTTP desde el navegador. (por ejemplo, esto es lo que vería si examinara el tráfico con Fiddler o HttpWatch)

Sin embargo, ASP.NET loa esto (y otra información de solicitud) en una instancia System.Uri, que analiza la cadena de solicitud en sus partes constituyentes . En este caso, "host" se refiere literalmente a la parte de la máquina host de la solicitud original (por ejemplo, con el puerto tcp en el puerto).

Esta clase System.Uri es una clase de ayuda muy útil que elimina todo el dolor de dividir su solicitud en sus partes, mientras que el "Host:" (y para el caso el "OBTENER") del encabezado http son simplemente raw datos de solicitud.

A pesar de que ambos tienen el mismo nombre, que no están destinados a ser lo mismo.

+0

Gracias por su respuesta, lo que me pregunto es cómo 'dividir' http://dev.testhost.com:1234/ puede resultar en la pérdida completa de la parte 'dev.testhost.com', y hacer que sea reemplazada por 'localhost'? Mi pregunta no era realmente acerca de las clases de Uri o UriBuilder, entiendo bien eso;) Además, ** el número de puerto no es el problema aquí en absoluto **. He agregado ** énfasis ** al 3er párrafo de mi pregunta, ¿quizás eso lo aclarará? Gracias de nuevo;) –

+0

Bueno, ha dicho que ha asociado dev.testhost.com con la dirección IP 127.0.0.1. Sin embargo, esta dirección IP siempre se asigna al host local (por definición, es la dirección de bucle invertido), por lo que cualquier búsqueda de nombre en 127.0.0.1 se asignará a localhost. Cuando dices "asociar dev.testhost.com con 127.0.0.1" ¿cómo hiciste esto? ¿Editó el archivo de hosts, o lo hizo de otra manera? –

+0

Agregué la entrada en el archivo de hosts. Consulte la respuesta de kiamlaluno a continuación ... Parece que este es un problema específico de Cassini ... –

Cuestiones relacionadas