Autor en Google+
Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

10 años online 🎂

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET, ASP.NET Core, MVC, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
martes, 22 de enero de 2013
ASP.NET MVCHace poco veíamos que el nuevo sistema de routing usado por proyectos MVC 4 permitía una cierta configuración del formato de URL generadas por la aplicación al usar helpers como Url.Action() o Html.ActionLink(), y cómo usando una simple línea de código podíamos hacer que las rutas se generaran usando sólo minúsculas.

Pues bien, al igual que en ese caso, en los proyectos que usen la última versión del ensamblado System.Web.Routing, por ejemplo si compilamos aplicaciones Webforms, MVC 3 o 4 para .NET 4.5, también es posible hacer que las URLs generadas acaben con una barra inclinada estableciendo a true la propiedad AppendTrailingSlash :
public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.AppendTrailingSlash = true;

    routes.MapRoute(
        name: "Default",
        url: "{controller}/{action}/{id}",
        defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
    );
}
La siguiente tabla muestra algunos ejemplos de cómo afecta el valor de esta propiedad a la hora de generar una ruta:

Instrucción AppendTrailingSlash
true false
Url.Action("About", "Home") /Home/About/ /Home/About
Url.Action("Edit", "Product", new {id = 1}) /Product/Edit/1/ /Product/Edit/1
Url.Action("Edit", "Product", new {id = 1, x=2}) /Product/Edit/1/?x=2 /Product/Edit/1?x=2

Pero, ¿por qué tendríamos que añadir una barra al final de las URL?

Es cierto que, siguiendo las tradiciones y buenas costumbres de siempre, una URL debería acabar en una barra si no apunta a un archivo con objeto de facilitar la vida al servidor. Una petición a la dirección servidor.com/algo es ambigua porque el servidor, a priori, no puede conocer si el recurso solicitado "algo" es un archivo o un directorio; si, en cambio, la petición se realiza hacia servidor.com/algo/ queda más claro que lo que se pretende es obtener el contenido de una carpeta, y en teoría podría agilizarse el proceso de búsqueda del recurso.

No he encontrado tampoco directrices que indiquen claramente en qué afecta la aparición de esa terminación en la respuesta que debe enviar el servidor. Podemos encontrar servidores que ante una petición como servidor.com/algo retornan el mismo recurso que si la URL incluyera la barra final; en otros, en cambio, se opta por retornar una redirección hacia servidor.com/algo/ (con la barra) con objeto de indicar al cliente que "esa dirección es la buena" y evitar contenidos duplicados (el mismo contenido accesible desde distintas URL). Esto último podéis comprobarlo creando una aplicación web cualquiera y accediendo a localhost:xxx/content mientras trazáis las peticiones con Fiddler o las developer tools.

En aplicaciones ASP.NET en las se usa el sistema de routing, donde no existe el concepto "directorio" como tal, el uso de estas barras no tienen demasiado sentido. Por ejemplo, en MVC las peticiones se mapean contra acciones en un controlador; en la práctica, da igual si una URL acaba o no con una barra, puesto que será procesada por la misma acción y retornará el mismo resultado.

Por tanto, con este tipo de sistemas probablemente la elección se trate más de una cuestión de gustos que otra cosa. Simplemente va de decidir un estilo y ceñirse a él en toda la aplicación; y si lo que elegimos es acabar las URL con barras, ya sabemos que el sistema de routing de ASP.NET lo soporta de serie :-)

Por mi parte, hasta ahora nunca he usado las barritas en las URL y, salvo que encuentre algún buen motivo, creo que seguiré sin hacerlo.

Y vosotros, ¿qué opináis del tema? ¿Barra sí o barra no? (Y no me refiero a las de los bares ;-P)

Publicado en: Variable not found.

Estos contenidos se publican bajo una licencia de Creative Commons Licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons

2 Comentarios:

Javier M dijo...

Hola qué tal, en lo que respecta a los buscadores toman como URL's diferentes las que terminan con la barra (trailing slash) de las que no (cuando por la razón que sea se generan ambas).

Así, se entiende que son diferentes las siguientes:

http://www.variablenotfound.com/
http://www.variablenotfound.com

En caso de que al cargarlas en el navegador web y una no rediriga a la otra (da igual cuál elegir) estaríamos teniendo problemas de contenido duplicado interno, y lo mismo sucedería si lleva o no el 'www':

http://www.variablenotfound.com/
http://variablenotfound.com

Saludos !

José M. Aguilar dijo...

Hola, Javier!

Muchas gracias por tu comentario y aclaración. Efectivamente, el SEO es una variable a tener en cuenta para no ser penalizado :-)

Hay que elegir un modelo de generación de URL (con barra o sin barra, el que sea), y simplemente ceñirse siempre a él para evitar esos problemas de duplicidad de contenidos.

... Por tanto, seguiré sin usar las barras, como hasta ahora ;-)

Un saludo & muchas gracias! :-)