asp.net HttpHandler personalizado y enrutamiento de URL

Question

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

Por lo tanto, los usuarios que accedan 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.

He oído 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 sobre este tema.

Saludos Frank Abel

Answer 1

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

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

Desde este redirige todas las URL para su sitio web/aplicación a su manejador, debe considerar cómo servir contenido estático (imgs, scripts, hojas de estilo, etc.). Una forma es la de almacenar dicho contenido estático en una misma URL como http://example.com/static/..., a continuación, puede configurar sus controladores como tal:

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

Por su servidor web dev local (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 (ya 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).

• abierta: Administrador de IIS ->
• Sección: Sitios Web ->
• clic derecho en su página web ->
• Opción: Propiedades ->
• Tab: Inicio Directory ->
• Botón: [Configuración ...] ->
• Pestaña: Asignaciones ->
• Sección: "Mapas de aplicaciones comodín (orden de implementación) : "->
• Botón: [Insertar ...] ->
• ejecutable: "C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ aspnet_isapi.dll" (o cualquier versión del tiempo de ejecución de .NET utiliza el controlador) ->
• Desactive la opción "Verificar que archivo existe" ->
• Botón: [OK]

Ahora IIS y ASP.NET sabe cómo hacer frente a sus URL.

El enfoque anterior significa que cuando se solicitan archivos estáticos, ASP.NET está realmente sirviendo los archivos, no IIS, lo que conlleva algunas desventajas (discutido here). 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 de una aplicación. Voilà: IIS maneja los archivos estáticos sin molestar a su ASP.NET.

Answer 2

no recomiendo la combinación de enrutamiento de URL y HTTP manipuladores.

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

Simplemente asigna "~/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 una cuestión completamente diferente y no deben utilizarse 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 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 al respecto - Basic Routing for HttpHandler