Dans le monde du développement web, le terme "redirection" désigne l'action d'envoyer au client une réponse HTTP vide, avec seulement un mot de passe. Location contenant la nouvelle URL à laquelle le client doit envoyer une toute 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 suivant
other.jsp .
Vous pouvez le suivre avec les outils de développement intégrés ou complémentaires du navigateur Web. Appuyez sur F12 dans Chrome/IE9/Firebug et vérifiez la section "Réseau" pour le voir.
Exactement ce qui précède est réalisé par sendRedirect("other.jsp") . Le site RequestDispatcher#forward() n'envoie pas de redirection. Au lieu de cela, il utilise le contenu de la 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 suivant
other.jsp .
Cependant, comme la requête HTTP originale était destinée à some.jsp l'URL dans la barre d'adresse du navigateur reste inchangée. De même, tous les attributs de requête définis dans le contrôleur derrière l'élément some.jsp sera disponible en other.jsp . Cela ne se produit pas lors d'une redirection, car vous forcez le client à créer un fichier nouveau Demande HTTP sur other.jsp en rejetant ainsi la demande initiale sur some.jsp y compris tous ses attributs.
Le site RequestDispatcher est extrêmement utile dans le paradigme MVC et/ou lorsque vous voulez cacher les JSP d'un accès direct. Vous pouvez placer les JSP dans le répertoire /WEB-INF et utiliser un Servlet qui contrôle, pré-traite et post-traite les demandes. Les JSPs dans le /WEB-INF ne sont pas directement accessibles par l'URL, mais le dossier Servlet peut y accéder en utilisant RequestDispatcher#forward() .
Vous pouvez par exemple avoir un fichier JSP dans le répertoire /WEB-INF/login.jsp et un LoginServlet qui est mappé sur un url-pattern de /login . Lorsque vous invoquez http://example.com/context/login alors l'élément doGet() sera invoquée. Vous pouvez faire pré le traitement des affaires là-dedans et finalement avant 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, la servlet doPost() sera invoqué et vous pourrez faire tout poste le traitement des données qui s'y trouvent (par exemple, la validation, la logique commerciale, la connexion de l'utilisateur, etc.)
S'il y a des erreurs, alors vous devez normalement avant la demande est renvoyée à la même page et les erreurs sont affichées à côté des champs de saisie, etc. Vous pouvez utiliser la fonction RequestDispatcher pour ça.
Si un POST est réussie, vous voulez normalement rediriger la demande, afin qu'elle ne soit pas soumise à nouveau lorsque l'utilisateur actualise la demande (par exemple en appuyant sur F5 ou en remontant 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 rediriger demande donc au client de lancer un nouveau GET sur l'URL donnée. L'actualisation de la demande ne rafraîchira alors que la demande redirigée et non la demande initiale. Cela évitera les "doubles soumissions", la confusion et les mauvaises expériences des utilisateurs. Cette méthode est également appelée POST-Redirect-GET motif .
Voir aussi :
