asp.net HttpHandler personalizado y enrutamiento de URL

routing

Question

Quiero manejar las solicitudes a mi aplicación "http://example.com/whateverpath" mediante un HttpHandler personalizado pero las cosas de retorno dependen del valor de "whateverpath".

Por lo tanto, los usuarios que acceden a "http://example.com/path1" obtendrán una respuesta diferente a la de los usuarios que acceden a "http://example.com/path2", pero ambas solicitudes deben manejarse en el mismo HttpHandler. La idea es encontrar "cualquier camino" en una base de datos y, dependiendo del resultado, devolver el contenido de la respuesta.

Escuché sobre el enrutamiento de URL y ya tengo un controlador Http personalizado funcionando, pero ¿puedo combinar ambas técnicas para obtener lo que necesito?

Agradeceré cualquier comentario respecto a este tema.

Saludos Frank Abel

Answer 1

No recomiendo combinar el enrutamiento de URL y los controladores HTTP.

Esto parece ser un trabajo perfecto para el enrutamiento de URL. Sin embargo, no usaría un controlador HTTP para eso.

Simplemente asigne "~ / CustomData / whateverpath" a una página ASPX. Luego haga que la página cargue los datos de la base de datos. Después de todo, si la lógica para buscar los datos es la misma sin importar qué sea "lo que sea el camino", no quiere repetir su lógica para cada variación. En su lugar, desea asignarlo a un único archivo que cargará los datos correctos para todos los casos.

Los manejadores HTTP son un asunto completamente diferente y no deberían usarse para este propósito. (Por cierto, acabo de publicar un artículo sobre los controladores HTTP. Puede verlo en http://www.blackbeltcoder.com/Articles/asp/writing-a-custom-http-handler-in-asp-net ).

Answer 2

Así que tiene una clase que implementa IHttpHandler llamado: MyHandler y está en el espacio de nombres Example , necesita hacer las siguientes entradas en la Web.Config del sitio en la sección httpHandlers :

<httpHandlers>
<add verb="*" path="*" type="Example.MyHandler"/>
</httpHandlers>

Dado que esto redirige todas las URL de su sitio web / aplicación a su controlador, debe considerar cómo enviar contenido estático (imágenes, scripts, hojas de estilo, etc.). Una forma es almacenar dicho contenido estático en una URL consistente como http://example.com/static/... , luego puede configurar sus manejadores como tales:

<httpHandlers>
<add verb="*" path="*" type="Example.MyHandler"/>
<add verb="GET,HEAD" path="static/*" type="System.Web.StaticFileHandler" />
</httpHandlers>

Para su servidor web local de desarrollo (integrado en Visual Studio) esto es todo lo que se necesita. Para IIS, también debe decirle a IIS cómo tratar con estas URL (dado que el servidor primero analiza una solicitud para decidir dónde enviarla, incluso si debe enviarla a ASP.NET o a alguna otra extensión).

• Abrir: Administrador de IIS ->
• Sección: Sitios web ->
• Haga clic derecho en su sitio web ->
• Opción: Propiedades ->
• Pestaña: Home Directoy ->
• Botón: [Configuración ...] ->
• Pestaña: Asignaciones ->
• Sección: "Mapas de aplicaciones de comodines (orden de implementación):" ->
• Botón: [Insertar ...] ->
• Ejecutable: "C: / WINDOWS / Microsoft.NET / Framework / v2.0.50727 / aspnet_isapi.dll" (o la versión del tiempo de ejecución de .NET que use su controlador) ->
• Desmarque "Verificar que el archivo existe" ->
• Botón: [OK]

Ahora, tanto IIS como ASP.NET saben cómo manejar sus URLS.

El enfoque anterior significa cuando se solicitan archivos estáticos, ASP.NET está realmente sirviendo los archivos, no IIS, lo que genera algunas desventajas (que se analizan aquí ). Puede anular este comportamiento (deshabilitar la asignación de comodines desde el directorio estático) cambiando el directorio a una aplicación (en el Administrador de IIS), eliminando la declaración de asignación de comodines (agregada arriba) y volviendo a cambiarla desde una aplicación. Voilà: IIS maneja los archivos estáticos sin molestar a su ASP.NET.

Answer 3

En primer lugar, estoy de acuerdo con la publicación anterior de Jonathan Wood, que el uso de enrutamiento dentro de HttpHandler no es una buena idea. Pero estoy bastante seguro de que se estaba refiriendo a la ruta MVC estándar allí.

Un buen enfoque sería utilizar el enrutamiento personalizado. Publiqué un artículo sobre esto: Basic Routing for HttpHandler