Saltar al contenido

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

17 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 Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
lunes, 26 de marzo de 2018
martes, 20 de marzo de 2018
HTTP Como sabemos, los conocidos códigos de estado HTTP 301 y 302 se usan para retornar al agente de usuario (normalmente, el navegador) una redirección, que viene a ser algo así como decirle “hey, el recurso que andas buscando ya no se encuentra aquí, sino en esta otra dirección”.

Presto y obediente, el browser interpretará esta orden navegando hacia la URL indicada en el encabezado location del resultado, es decir, generando una nueva petición de tipo GET y mostrando al usuario la página obtenida.

Un ejemplo del workflow de peticiones y respuestas de este tipo podría ser la siguiente:
// Petición:
GET /home/articles/welcome-to-my-blog.html HTTP/1.1
Host: www.myserver.com

// Respuesta:
HTTP/1.1 301 Moved Permanently
Location: http://www.myserver.com/blog/welcome-to-my-blog.html

// Nueva petición:
GET /blog/welcome-to-my-blog.html HTTP/1.1
Host: www.myserver.com
...
La diferencia entre el código 301 y 302 es que el primero de ellos indica al agente de usuario (sea un browser o aplicación cliente) que la redirección es permanente, esto es, que puede almacenar localmente la nueva ubicación y utilizarla en el futuro con seguridad en lugar de la que se usó originalmente. El código 302, en cambio, indica que la nueva ubicación es temporal y sólo debe ser utilizada en esta ocasión para dirigir la petición al lugar correcto.

Los códigos de estado HTTP 301 y 302 son válidos en la mayoría de escenarios, y permiten solucionar problemas como, entre otros, el cambio de ubicación nuestros recursos sin perder posicionamiento en buscadores, o implementar el patrón Post-Redirect-Get para mejorar un poco la experiencia de usuario y evitar dobles envíos de información en formularios.

Sin embargo, hay ocasiones en que la solución queda algo corta. Por ejemplo, si cambiamos de URL el endpoint de un servicio programado exclusivamente para ser invocado mediante peticiones de tipo POST o PUT, lo que nos interesaría sería que las peticiones a la dirección original retornaran una redirección indicando la nueva ubicación pero también informando al browser de que utilice sobre ella el mismo verbo de la petición original.

Por ello, y algunas otras razones que veremos después, el estándar HTTP amplió, hace ya bastante tiempo, el conjunto de códigos de redirección con tres nuevos miembros: HTTP 303, 307 y 308. Los dos primeros formaron parte de HTTP 1.1, mientras que el código 308 fue añadido en la RFC 7538 algo más adelante.

Veamos para qué sirve cada uno de ellos.
lunes, 19 de marzo de 2018
Enlaces interesantes
Pues tras un par de semanitas de parón debido a mi excursión al MVP Summit, volvemos a la carga con un buen puñado de enlaces que, como siempre, espero que os resulten interesantes :-)

.NET / .NET Core

jueves, 1 de marzo de 2018
Seattle

Pues creo que habré visitado Redmond ya en ocho o nueve ocasiones, pero la verdad es que la semana del MVP Global Summit sigue siendo una de esas épocas del año que espero con más entusiasmo. Y por fin, ya toca dentro de unos días ;)

Una vez más, allí tendré ocasión de disfrutar de la compañía de amigos que sólo veo una vez al año, de respirar un ambiente geek++ inigualable, y, por supuesto, del lujazo de aprender y profundizar sobre las tecnologías lo que tenemos por delante de mano de los propios padres de las criaturas. Bueno, y siempre mola quitarse un poco del día a día y hacerse un viajillo al otro lado del mundo :)

¡Nos vemos por aquí a la vuelta!

Publicado en Variable not found.

MVP Global Summit 2018