2008-11-16 12 views
24

que estoy tratando de hacer url semántica de las páginas de búsqueda, pero si alguien usar una búsqueda terminada en punto, el motor .net devolver un 404.url semántica con puntos en .net

La solicitud ni siquiera llegar al motor de enrutamiento, así que creo que es algo relacionado con la seguridad o algo así. Por ejemplo, las rutas de stackoverflow tampoco funcionan en estos casos: https://stackoverflow.com/questions/tagged/etc.

+0

Necesita más información. ¿Qué tecnología .NET exacta estás usando para hacer el enrutamiento? Es este ASP.NET MVC también me gusta stackoverflow.com? – BuddyJoe

+0

no, es monorraíl de castillo, pero no importa, ya que la solicitud no entra en el código de marco. He visto este error en los sitios de webforms clásicos, asp.net mvc ones y monorrail también. Debe ser algo relacionado con el servidor web, pero no puedo encontrar nada al respecto en el documento. – Jokin

Respuesta

23

Si está utilizando .NET 4.0 y IIS 7+, se puede establecer esta bandera en la sección system.web de su web.config y se le permitirá:

<httpRuntime relaxedUrlToFileSystemMapping="true" /> 

Lo he probado y funciona. Haack tiene una explicación de eso.

+13

Lo he probado y no funciona. – PabloC

+0

Esto tampoco funcionó en mi caso. – Roger

+2

@Roger requiere iis7. Agregué eso a la respuesta. – bkaid

0

Parece que IIS podría no saber cómo manejar una solicitud con una extensión vacía.

Haga clic derecho en el sitio web y seleccione "Propiedades". Haga clic en "Configuración ..." en la pestaña "Directorio de inicio". Mire las "Extensiones de aplicación" e intente agregar una extensión vacía o comodín.

+0

No lo creo, también ocurre en el servidor web de Visual Studio, donde todas las extensiones son administradas por .net handler. en mi caso, la url es como http://search.com/search/search-term-with-dot./location.aspx – Jokin

+0

Hmm si obtiene el error en VS también está seguro de que no tiene un ignorar ruta que está siendo golpeado? –

+0

al depurarlo, la solicitud no llega al punto de interrupción en el motor de rutina. Si ve los enlaces que publiqué en el comentario a stefan, el tratamiento de ambos es muy diferente, uno es manejado por el controlador registrado 404 y el otro por defecto. – Jokin

-1

En Windows, los nombres de archivo no pueden terminar con un '.' Creo que todos los problemas provienen de allí, es decir, IIS no sabe qué hacer con él, por lo que nunca llega tan lejos como el controlador de errores de ASP.NET y obtiene identificadores de la página IIS 404 predeterminada.

La mayoría de los motores de búsqueda (well Google anyway) excluyen la puntuación de las consultas, y creo que la suya también.

EDITAR: Se cae porque no tiene ningún tipo de archivo, incluso el sitio de Microsoft se cae sobre el aspecto http://www.microsoft.com/en/us/fallover. pero puede modificar los archivos de error predeterminados (en vivo en algún lugar como C: \ WINDOWS \ help \ iisHelp \ common) o cambiarlo por completo.

comprobar éste hacia fuera: Configuring Custom Error Messages (IIS 6.0)

+1

Seguramente, los nombres de archivos pueden terminar con '.' en Windows. – Terminus

+0

No es difícil averiguar – inspite

+1

No es cierto, y el sistema de enrutamiento en ASP.NET no tiene nada que ver con los nombres de archivo. –

-2

No se debe poner búsquedas exactas de usuario en la cadena de consulta de esa manera ... que debe urlencode ellos. Eso resolverá el problema.

+0

el punto es un carácter válido en la url, por lo que si urlencode algo con un punto, seguirá siendo el mismo. – Jokin

+0

Es cierto ...% 2E funcionaría bien. –

+1

no, eche un vistazo a http://stackoverflow.com/questions/294495/semantic-urls-with-dots-in-net%2E – Jokin

8

Todo después del '.' es la extensión de archivo. Si esa extensión no está asignada a ASP.NET, no se transferirá al controlador de ASP.NET. IIS busca un archivo estático en su lugar. De ahí el 404. Si no agrega nada (y es difícil ver cómo sería), sugiero que se elimine.

+0

Pero también ocurre en el servidor web de Visual Studio, donde todas las solicitudes están mapeados a asp.net. Debe ser un controlador anterior o una medida de seguridad. Incluso las solicitudes de archivos estáticos pasan a través de mis controladores. Pero si la solicitud tiene un "./" en cualquier posición, es un no no – Jokin

+0

No creo que pueda hacer inferencias razonables de cómo se comporta el servidor de desarrollo. Por lo que sabemos, conoce este problema con IIS y está haciendo todo lo posible para comportarse de la misma manera. Al final, no importa, porque vas a implementar con IIS, no con Cassini. – dpurrington

1

Cuando el período final no es significativo (como es el caso de https://stackoverflow.com/questions/tagged/etc.) puede usar el módulo Reescribir URL de IIS para quitar los períodos finales.

Patrón: URL ^(.*[^.])(\.+)$
reescritura:{R:1}

Esto no va a ayudar cuando tirar el período no es una opción, o hay períodos al final de los segmentos de trazado intermedios, pero para el caso de uso muy real de lidiar con períodos que se agregan a las URL mediante algoritmos de enlace automático, puede ser útil.

Cuestiones relacionadas