Repository navigation
auto prg
Responde cada pregunta antes de ver la respuesta.
¿Cuál es el problema que resuelve el patrón PRG?
- A) El problema de que los formularios no pueden enviar datos a la base de datos
- B) La falta de seguridad en las peticiones HTTP
- C) El doble envío accidental de un formulario POST cuando el usuario recarga la página
- D) Los errores de compilación en los Servlets
Ver respuesta
✅ C) El doble envío accidental de un formulario POST cuando el usuario recarga la página
💡 Si el servidor responde al POST con HTML directamente, el navegador guarda ese POST en su historial. Al presionar F5, el navegador repite el POST y los datos se guardan dos veces en la BD.
¿Qué significa PRG?
- A) Protocol Request Generator
- B) Post-Redirect-Get
- C) Page Render Group
- D) Persistent Request Guard
Ver respuesta
✅ B) Post-Redirect-Get
💡 El patrón tiene tres pasos: recibir el POST, procesar los datos, y en lugar de responder con HTML, enviar un Redirect para que el navegador haga un nuevo GET.
¿Qué método del Servlet implementa el paso "Redirect" del patrón PRG?
- A)
request.getRequestDispatcher(...).forward(...) - B)
response.sendRedirect(url) - C)
response.setHeader("Redirect", url) - D)
request.sendRedirect(url)
Ver respuesta
✅ B) response.sendRedirect(url)
💡 sendRedirect envía un código HTTP 302 al navegador, que automáticamente hace una nueva petición GET a la URL indicada. Esa URL GET queda en el historial, no el POST original.
¿Qué ocurre en el navegador cuando el servidor hace un sendRedirect?
- A) La página se recarga sin cambiar la URL
- B) El servidor envía directamente el HTML al navegador
- C) El navegador bloquea la petición por seguridad
- D) El navegador recibe el código 302 y automáticamente hace una nueva petición GET a la nueva URL
Ver respuesta
✅ D) El navegador recibe el código 302 y automáticamente hace una nueva petición GET a la nueva URL
💡 Con sendRedirect hay 2 peticiones HTTP. La URL que queda en el historial del navegador es la del GET final, no la del POST. Si el usuario presiona F5, solo repite el GET (listar), no el POST (insertar).
¿Cuándo debería usarse forward() en lugar de sendRedirect()?
- A) Para mostrar vistas (listar, formulario vacío) sin modificar datos
- B) Después de insertar, actualizar o eliminar datos
- C) Siempre, porque
forwardes más rápido - D) Solo cuando hay un error en el servidor
Ver respuesta
✅ A) Para mostrar vistas (listar, formulario vacío) sin modificar datos
💡 La regla: si estás MOSTRANDO datos → forward. Si estás MODIFICANDO datos (insertar/actualizar/eliminar) → sendRedirect. El forward conserva atributos del request y es ideal para pasar datos al JSP.
En el patrón PRG aplicado al CRUD, ¿cuál es la secuencia correcta al agregar una persona?
- A) POST /personas → doPost inserta en BD → sendRedirect a GET /personas → doGet lista
- B) GET /personas → doPost inserta → forward a lista.jsp
- C) POST /personas → doPost inserta en BD → forward a lista.jsp
- D) GET /personas → doGet inserta → sendRedirect a POST /personas
Ver respuesta
✅ A) POST /personas → doPost inserta en BD → sendRedirect a GET /personas → doGet lista
💡 Este es el flujo PRG completo: el POST procesa la inserción, el sendRedirect provoca un GET, y el GET muestra la lista actualizada. Si el usuario recarga, solo repite el GET (inofensivo).
¿Cuál es el efecto del patrón PRG en el historial del navegador?
- A) El POST queda guardado en el historial para poder reenviar fácilmente
- B) El navegador borra todo el historial después de un PRG
- C) El historial guarda la URL del GET final, no el POST, por lo que F5 repite el GET (inofensivo)
- D) El historial no se ve afectado; F5 siempre repite el último POST
Ver respuesta
✅ C) El historial guarda la URL del GET final, no el POST, por lo que F5 repite el GET (inofensivo)
💡 Este es el beneficio clave del PRG: la URL que queda en la barra del navegador es la del GET. Al presionar F5, el navegador repite el GET (mostrar lista), no el POST (insertar datos).
