RequestDispatcher.forward () vs HttpServletResponse.sendRedirect()

tout d'abord, le terme "redirect" est dans le monde du développement web l'action d'envoyer au client une réponse HTTP vide avec juste un en-tête Location avec là la nouvelle URL sur laquelle le client doit envoyer une nouvelle demande GET. Donc en gros:

• le Client envoie une requête HTTP à some.jsp .
Le serveur
• renvoie une réponse HTTP avec Location: other.jsp en-tête
Le Client
• envoie une requête HTTP à other.jsp (cela se reflète dans la barre d'adresse du navigateur!)
Le serveur
• renvoie une réponse HTTP avec le contenu de other.jsp .

vous pouvez le suivre avec l'ensemble d'outils de développement builtin/addon du webbrowser. Appuyez sur F12 dans Chrome/IE9 / Firebug et vérifiez la section "Réseau" pour le voir.

exactement ce qui précède est atteint par sendRedirect("other.jsp") . Le RequestDispatcher#forward() n'envoie pas de redirection. Au lieu de cela, il utilise le contenu du page cible comme réponse HTTP.

• le Client envoie une requête HTTP à some.jsp .
Le serveur
• renvoie une réponse HTTP avec le contenu de other.jsp .

cependant comme la requête HTTP originale était some.jsp , L'URL dans la barre d'adresse du navigateur reste inchangée.

le RequestDispatcher est extrêmement utile dans le paradigme MVC et/ou lorsque vous je veux cacher les JSP de l'accès direct. Vous pouvez placer des JSP dans le dossier /WEB-INF et utiliser un Servlet qui contrôle, pré-traite et post-traite les requêtes. Les JSPs du dossier /WEB-INF ne sont pas directement accessibles par URL, mais le Servlet peut y accéder en utilisant RequestDispatcher#forward() .

vous pouvez par exemple avoir un fichier JSP dans /WEB-INF/login.jsp et un LoginServlet qui est mappé sur un url-pattern de /login . Quand vous invoquez http://example.com/context/login , alors le doGet() du servlet sera invoqué. Vous pouvez faire n'importe quel pré des trucs de traitement là-dedans et finalement forward la demande comme:

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

lorsque vous soumettez un formulaire, vous voulez normalement utiliser POST :

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

de cette façon, le servlet doPost() sera invoqué et vous pouvez faire n'importe quel post traitement des trucs là-dedans (par ex. validation, business la logique, de connexion de l'utilisateur, etc).

S'il y a des erreurs, alors vous voulez normalement envoyer la demande retour à la même page et y afficher les erreurs à côté des champs d'entrée et ainsi de suite. Vous pouvez utiliser le RequestDispatcher pour cela.

si une POST est réussie, vous voulez normalement rediriger la requête, de sorte que la requête ne sera pas présentée de nouveau lorsque l'utilisateur rafraîchit la demande (par exemple en appuyant sur F5 ou en naviguant de nouveau dans l'historique).

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.
}

A redirect demande ainsi au client de lancer une nouvelle requête GET sur L'URL donnée. Rafraîchir la requête ne ferait que rafraîchir la requête redirigée et non la requête initiale. Cela évitera la "double soumission" et la confusion et une mauvaise expérience de l'utilisateur. C'est également appelé le POST-Redirect-GET modèle .

l'interface RequestDispatcher vous permet de faire une redirection côté serveur/include tandis que sendRedirect() fait une redirection côté client. Dans une redirection côté client, le serveur renvoie un code D'état HTTP de 302 (redirection temporaire) qui amène le navigateur web à émettre une toute nouvelle requête HTTP GET pour le contenu à l'emplacement redirigé. En revanche, lorsqu'on utilise le RequestDispatcher interface, l'include / forward vers la nouvelle ressource est gérée entièrement du côté du serveur.

L'une ou l'autre de ces méthodes peut être "meilleure", c.-à-d. plus appropriée, selon ce que vous voulez faire.

une redirection côté serveur est plus rapide dans la mesure où vous obtenez les données d'une page différente sans faire un aller-retour vers le navigateur. Mais L'URL vue dans le navigateur est toujours l'adresse d'origine, donc vous créez une petite incohérence là.

une redirection côté client est plus polyvalent dans la mesure où il peut vous envoyer à un tout autre serveur, ou changer le protocole (par exemple de HTTP à HTTPS), ou les deux. Et le navigateur est au courant de la nouvelle URL. Mais il faut un échange supplémentaire entre le serveur et le client.

SendRedirect() va rechercher le contenu entre les serveurs. il est lent car il doit intimer le navigateur en envoyant L'URL du contenu. puis le navigateur créera une nouvelle requête pour le contenu dans le même serveur ou dans un autre.

RquestDispatcher est pour chercher le contenu dans le serveur je pense. c'est le processus côté serveur et il est plus rapide comparé à la méthode SendRedirect() . mais le truc, c'est qu'il ne sera pas intime le navigateur dans lequel serveur il recherche la date ou le contenu requis, ni il ne demandera au navigateur de changer L'URL dans L'onglet URL. cela cause donc peu d'inconvénients à l'utilisateur.

Request Dispatcher est une Interface qui est utilisée pour envoyer la requête ou la réponse d'une ressource web à une autre ressource Web. Elle contient principalement deux méthodes.

1. request.forward(req,res) : cette méthode est utilisée pour transmettre la requête d'une ressource web à une autre ressource. I. e d'un servlet à un autre servlet ou d'une application web à une autre application web.

2. response.include(req,res) : ce la méthode utilisée comprend la réponse d'un servlet à un autre servlet

NOTE: en utilisant Request Dispatcher nous pouvons transmettre ou inclure la ou les requêtes avec dans le même serveur.

request.sendRedirect() : en utilisant ceci nous pouvons transmettre ou inclure la demande ou les réponses à travers les différents serveurs. En cela, le client reçoit une notification tout en redirigeant la page, mais dans le processus, le client ne sera pas obtenir d'annonce

la redirection technique doit être utilisée soit si nous avons besoin de transférer le contrôle à un autre domaine ou pour réaliser la séparation des tâches.

Par exemple dans la demande de paiement nous effectuons d'abord le processus de paiement puis nous redirigeons vers displayPaymentInfo. Si le client rafraîchit le navigateur, seul le displayPaymentInfo sera refait et le processus de paiement ne sera pas répété. Mais si nous utilisons forward dans ce scénario, à la fois le processus de paiement et displayPaymentInfo seront ré-exécuté séquentiellement, ce qui peut conduire à des données incohérentes.

pour les autres scénarios, forward est efficace à utiliser car il est plus rapide que sendRedirect

la principale différence importante entre la méthode forward() et sendRedirect() est que dans le cas de forward (), redirect arrive à la fin du serveur et non visible pour le client, mais en cas de sendRedirect (), redirection se produit à la fin du client et il est visible client.