jsp redirect servlets forward

jsp - RequestDispatcher.forward() frente a HttpServletResponse.sendRedirect()



servlets (7)

Método requestDispatcher - forward ()

  1. Cuando usamos el método de envío, la solicitud es transferencia a otro recurso dentro del mismo servidor para su posterior procesamiento.

  2. En caso de reenvío, el contenedor web maneja todo el proceso internamente y el cliente o el navegador no están involucrados.

  3. Cuando se invoca reenvío en el objeto requestdispatcher, pasamos los objetos de solicitud y respuesta para que nuestro antiguo objeto de solicitud esté presente en el nuevo recurso que va a procesar nuestra solicitud.

  4. Visualmente, no podemos ver la dirección reenviada, es transparente.

  5. El uso del método forward () es más rápido que el envío de redirigir.

  6. Cuando redirigimos el uso de reenvío y queremos utilizar los mismos datos en un nuevo recurso, podemos usar request.setAttribute () ya que tenemos un objeto de solicitud disponible.

SendRedirect

  1. En el caso de sendRedirect, la solicitud se transfiere a otro recurso a un dominio diferente o a un servidor diferente para su posterior procesamiento.

  2. Cuando utiliza sendRedirect, el contenedor transfiere la solicitud al cliente o al navegador para que la URL que se proporciona dentro del método sendRedirect sea visible como una nueva solicitud al cliente.

  3. En el caso de una llamada a sendRedirect, los objetos antiguos de solicitud y respuesta se pierden porque el navegador los trata como una nueva solicitud.

  4. En la barra de direcciones, podemos ver la nueva dirección redireccionada. No es transparente.

  5. sendRedirect es más lento porque se requiere un viaje de ida y vuelta adicional, porque se crea una solicitud completamente nueva y se pierde el objeto de solicitud anterior. Se requiere dos solicitudes de navegador.

  6. Pero en sendRedirect, si queremos usar tenemos que almacenar los datos en sesión o pasar junto con la URL.

¿Cual es bueno?

Depende del escenario que método sea más útil.

Si desea que el control se transfiera a un nuevo servidor o contexto y se trate como una tarea completamente nueva, entonces vamos a Enviar redireccionamiento. En general, se debe usar el reenvío si la operación se puede repetir con seguridad cuando la recarga de un navegador de la página web no afecte el resultado.

Source

¿Cuál es la diferencia conceptual entre forward() y sendRedirect() ?

Cualquiera de estos métodos puede ser "mejor", es decir, más adecuado, dependiendo de lo que desee hacer.

Una redirección del lado del servidor es más rápida en la medida en que obtienes los datos de una página diferente sin hacer un viaje redondo al navegador. Pero la URL que se ve en el navegador sigue siendo la dirección original, por lo que está creando una pequeña inconsistencia allí.

Una redirección del lado del cliente es más versátil en la medida en que puede enviarte a un servidor completamente diferente, o cambiar el protocolo (por ejemplo, de HTTP a HTTPS), o ambos. Y el navegador conoce la nueva URL. Pero se necesita un intercambio adicional entre el servidor y el cliente.

En primer lugar, el término "redirigir" es en el mundo del desarrollo web la acción de enviar al cliente una respuesta HTTP vacía con solo un encabezado de Location con la nueva URL en la que el cliente debe enviar una nueva solicitud GET. Así que básicamente:

  • El cliente envía una solicitud HTTP a some.jsp .
  • El servidor envía una respuesta HTTP de vuelta con Location: other.jsp encabezado Location: other.jsp
  • El cliente envía una solicitud HTTP a other.jsp (¡esto se refleja en la barra de direcciones del navegador!)
  • El servidor envía una respuesta HTTP con contenido de other.jsp .

Puede rastrearlo con el conjunto de herramientas desarrollador / complemento de webbrowser. Presione F12 en Chrome / IE9 / Firebug y revise la sección "Red" para verla.

Exactamente lo anterior se logra mediante sendRedirect("other.jsp") . El RequestDispatcher#forward() no envía un redireccionamiento. En cambio, usa el contenido de la página de destino como respuesta HTTP.

  • El cliente envía una solicitud HTTP a some.jsp .
  • El servidor envía una respuesta HTTP con contenido de other.jsp .

Sin embargo, como la solicitud HTTP original era para some.jsp , la URL en la barra de direcciones del navegador permanece sin cambios.

RequestDispatcher es extremadamente útil en el paradigma de MVC y / o cuando quiere ocultar las JSP del acceso directo. Puede colocar JSP en la carpeta /WEB-INF y usar un Servlet que controla, preprocesa y posprocesa las solicitudes. No se puede acceder directamente a la carpeta JSP en /WEB-INF por URL, pero el Servlet puede acceder a ellos utilizando RequestDispatcher#forward() .

Por ejemplo, puede tener un archivo JSP en /WEB-INF/login.jsp y un LoginServlet mapeado en un url-pattern de /login . Cuando invoque http://example.com/context/login , se invocará el doGet() del servlet. Puedes hacer cualquier procesamiento previo y finalmente reenviar la solicitud como:

request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);

Cuando envía un formulario, normalmente desea usar POST :

<form action="login" method="post">

De esta forma, se doPost() el doPost() del servlet y podrá hacer cualquier procesamiento posterior allí (por ejemplo, validación, lógica comercial, inicio de sesión del usuario, etc.).

Si hay algún error, entonces normalmente desea reenviar la solicitud a la misma página y mostrar los errores allí al lado de los campos de entrada, y así sucesivamente. Puede usar RequestDispatcher para esto.

Si un POST se realiza correctamente, normalmente desea redirigir la solicitud, de modo que la solicitud no se vuelva a enviar cuando el usuario actualice la solicitud (por ejemplo, presionando F5 o retrocediendo en el historial).

User user = userDAO.find(username, password); if (user != null) { request.getSession().setAttribute("user", user); // Login user. response.sendRedirect("home"); // Redirects to http://example.com/context/home after succesful login. } else { request.setAttribute("error", "Unknown login, please try again."); // Set error. request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response); // Forward to same page so that you can display error. }

Una redirección ordena al cliente que active una nueva solicitud GET en la URL dada. Actualizar la solicitud solo actualizaría la solicitud redirigida y no la solicitud inicial. Esto evitará "envíos dobles" y confusión y mala experiencia del usuario. Esto también se llama el patrón POST-Redirect-GET .

La interfaz RequestDispatcher permite hacer un lado del servidor hacia adelante / incluir, mientras que sendRedirect() redirige al lado del cliente. En una redirección del lado del cliente, el servidor enviará un código de estado HTTP de 302 (redirección temporal) que hace que el navegador web emita una nueva solicitud HTTP GET para el contenido en la ubicación redireccionada. Por el contrario, cuando se utiliza la interfaz RequestDispatcher , el recurso incluir / reenviar al nuevo se maneja completamente en el lado del servidor.

Request Dispatcher es una interfaz que se utiliza para enviar la solicitud o respuesta desde el recurso web al otro recurso web. Contiene principalmente dos métodos.

  1. request.forward(req,res) : este método se utiliza para reenviar la solicitud de un recurso web a otro recurso. es decir, de un servlet a otro servlet o de una aplicación web a otra aplicación web.

  2. response.include(req,res) : este método se usa para incluir la respuesta de un servlet a otro servlet

NOTA: Al utilizar Request Dispatcher podemos reenviar o incluir la solicitud o respuestas en el mismo servidor.

request.sendRedirect() : AL usar esto podemos reenviar o incluir la solicitud o respuestas en los diferentes servidores. En esto, el cliente recibe una intimación mientras redirige la página, pero en el proceso anterior, el cliente no recibirá intimación

Técnicamente, la redirección debería usarse ya sea que necesitemos transferir el control a un dominio diferente o lograr la separación de la tarea.

Por ejemplo, en la aplicación de pago, hacemos el PaymentProcess primero y luego lo redirigimos a displayPaymentInfo. Si el cliente actualiza el navegador, solo se volverá a mostrar displayPaymentInfo y PaymentProcess no se repetirá. Pero si usamos forward en este escenario, tanto PaymentProcess como displayPaymentInfo se volverán a ejecutar secuencialmente, lo que puede dar como resultado datos incosistentes.

Para otros escenarios, reenviar es eficiente de usar ya que es más rápido que sendRedirect

SendRedirect() buscará el contenido entre los servidores. es lento porque tiene que intimidar al navegador enviando la URL del contenido. entonces el navegador creará una nueva solicitud para el contenido dentro del mismo servidor o en otro.

RquestDispatcher es para buscar el contenido dentro del servidor, creo. es el proceso del lado del servidor y es más rápido en comparación con el método SendRedirect() . pero la cuestión es que no intimará al navegador en el que está buscando la fecha o el contenido requerido, ni tampoco pedirá al navegador que cambie la URL en la pestaña URL. por lo que causa pocos inconvenientes para el usuario.