Post/Redirect/Get

Post/Redirect/Get (PRG), también conocido como Redirect After Post, es un patrón de diseño de desarrollo web que impide algunos envíos de formularios duplicados, creando una interfaz más intuitiva para los agentes de usuario (usuarios). PRG implementa marcadores y el botón Actualizar de un modo predecible que no crea envíos de formularios duplicados.

Diagrama de un problema de doble POST encontrado en agentes de usuario.

Diagrama del anterior problema del doble POST siendo resuelto por PRG.

Envíos de formularios duplicados

Cuando un formulario web es enviado a un servidor a través de una solicitud HTTP POST, un usuario web que intenta refrescar la respuesta del servidor en ciertos agentes de usuario puede hacer que el contenido de la solicitud HTTP POST original vuelva a enviarse, lo que podría producir resultados no deseados, como por ejemplo una compra web duplicada.

Para evitar este problema, muchos desarrolladores web utilizan el patrón PRG​ — en lugar de retornar directamente a una página web, la operación POST devuelve un comando de redireccionamiento. La especificación HTTP 1.1 introdujo el código de respuesta HTTP 303 ("Vea otra") para garantizar que, en esta situación, el navegador del usuario web puede refrescar con seguridad la respuesta del servidor sin que la solicitud inicial HTTP POST se vuelva a enviar. Sin embargo las aplicaciones comerciales más comunes en uso hoy en día (nuevas y viejas por igual) aún continúan emitiendo respuestas HTTP 302 ("Encontrado") en estas situaciones. El uso de HTTP 301 ("Movido permanentemente") es evitado generalmente porque los navegadores HTTP 1.1 no convierten el método a GET después de recibir el HTTP 301, puesto que es más comúnmente hecho para el HTTP 302.​ Sin embargo, el código HTTP 301 puede ser preferido en los casos en que no es deseable convertir los parámetros POST en parámetros GET para que así sean grabados en logs.

El patrón PRG no puede hacer frente a todos los escenarios de envío de formularios por duplicado. Algunos envíos de formularios duplicados conocidos que PRG no puede resolver son:

• Si un usuario web refresca antes de que el envío inicial se haya completado debido a lag en el servidor, resultando en una solicitud HTTP POST duplicada en algunos agentes de usuario.

Una alternativa comúnmente usada al patrón PRG es el uso de un "nonce" para evitar envíos de formularios duplicados.​

Marcadores

Los agentes de usuario (tales como los navegadores) almacenan solo el URI de una petición HTTP como un marcador. Debido a esto, una solicitud HTTP POST que resulta en una respuesta basada en el cuerpo de la solicitud HTTP POST no puede ser marcada. Al utilizar el patrón PRG, el URI de la petición HTTP GET pueden ser marcado con seguridad por un usuario web. Es una cuestión de la persistencia de los datos y el diseño de la URI si el marcado tiene sentido y está realmente trabajando en cada paso de una aplicación.

Servidores proxy

Puesto que las redirecciones están utilizando URI absolutos, uno tiene que tener cuidado con los servidores proxy (HTTP->HTTPS) y servidores proxy inversos. Si la aplicación es tal que un usuario utiliza un túnel SSL para llegar a su sitio, esto puede causar problemas también. (Puede ser posible utilizar la cabecera Referer para descubrir el dominio y el puerto por el que el usuario está realmente entrando.)

Enlaces externos

• Redirect After Post, Michael Jouravlev, August 2004
  • Descripción del patrón para J2EE, Michael Jouravlev, August 14, 2003
• GET after POST Adam Vandenberg
• Is the Portlet Programming Model Broken? Archivado el 19 de noviembre de 2013 en Wayback Machine. Subbu Allamaraju
• Hacer PRG en JSF1.2

• Datos: Q3399719