Réponses:
requestDispatcher - méthode forward ()
Lorsque nous utilisons la
forward
méthode, la demande est transférée vers une autre ressource du même serveur pour un traitement ultérieur.Dans le cas de
forward
, le conteneur Web gère tout le traitement en interne et le client ou le navigateur n'est pas impliqué.Quand
forward
est appelé sur l'requestDispatcher
objet, nous passons les objets de requête et de réponse, donc notre ancien objet de requête est présent sur la nouvelle ressource qui va traiter notre requête.Visuellement, nous ne pouvons pas voir l'adresse transmise, elle est transparente.
L'utilisation de la
forward()
méthode est plus rapide quesendRedirect
.Lorsque nous redirigeons en utilisant forward et que nous voulons utiliser les mêmes données dans une nouvelle ressource, nous pouvons utiliser
request.setAttribute()
car nous avons un objet de requête disponible.EnvoyerRedirect
Dans ce cas
sendRedirect
, la demande est transférée vers une autre ressource, vers un domaine différent ou vers un serveur différent pour un traitement ultérieur.Lorsque vous utilisez
sendRedirect
, le conteneur transfère la demande au client ou au navigateur, de sorte que l'URL donnée dans lasendRedirect
méthode est visible en tant que nouvelle demande au client.En cas d'
sendRedirect
appel, les anciens objets de requête et de réponse sont perdus car ils sont traités comme une nouvelle requête par le navigateur.Dans la barre d'adresse, nous pouvons voir la nouvelle adresse redirigée. Ce n'est pas transparent.
sendRedirect
est plus lent car un aller-retour supplémentaire est nécessaire, car une demande complètement nouvelle est créée et l'ancien objet de demande est perdu. Deux requêtes de navigateur sont requises.Mais dans
sendRedirect
, si nous voulons utiliser les mêmes données pour une nouvelle ressource, nous devons stocker les données en session ou les transmettre avec l'URL.Lequel est bon?
Cela dépend du scénario pour lequel la méthode est la plus utile.
Si vous voulez que le contrôle soit transféré vers un nouveau serveur ou contexte, et que cela soit traité comme une tâche complètement nouvelle, alors nous y allons
sendRedirect
. En règle générale, un transfert doit être utilisé si l'opération peut être répétée en toute sécurité lors d'un rechargement de la page Web par le navigateur et n'affectera pas le résultat.
Dans le monde du développement Web, le terme «redirection» est le fait d'envoyer au client une réponse HTTP vide avec juste un en- Location
tête contenant la nouvelle URL à laquelle le client doit envoyer une toute nouvelle requête GET. Donc en gros:
some.jsp
.Location: other.jsp
têteother.jsp
(cela se reflète dans la barre d'adresse du navigateur!)other.jsp
.Vous pouvez le suivre avec l'ensemble d'outils de développement intégré / complémentaire 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 RequestDispatcher#forward()
n'envoie pas de redirection. Au lieu de cela, il utilise le contenu de la page cible comme réponse HTTP.
some.jsp
.other.jsp
.Cependant, comme la requête HTTP d'origine l'était some.jsp
, l'URL dans la barre d'adresse du navigateur reste inchangée. De plus, tous les attributs de requête définis dans le contrôleur derrière some.jsp
seront disponibles dans other.jsp
. Cela ne se produit pas lors d'une redirection car vous forcez essentiellement le client à créer une nouvelle requête HTTP other.jsp
, rejetant ainsi la requête d'origine en some.jsp
incluant tous ses attributs.
Le RequestDispatcher
est extrêmement utile dans le paradigme MVC et / ou lorsque vous souhaitez masquer les JSP de l'accès direct. Vous pouvez placer les JSP dans le /WEB-INF
dossier et utiliser un Servlet
qui contrôle, pré-traite et post-traite les requêtes. Les JSP du /WEB-INF
dossier ne sont pas directement accessibles par URL, mais Servlet
peuvent 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
. Lorsque vous invoquez http://example.com/context/login
, le servlet doGet()
sera appelé. Vous pouvez faire n'importe quel pré- traitement là-dedans et enfin transmettre la demande comme:
request.getRequestDispatcher("/WEB-INF/login.jsp").forward(request, response);
Lorsque vous soumettez un formulaire, vous souhaitez normalement utiliser POST
:
<form action="login" method="post">
De cette façon, les servlets doPost()
seront invoqués et vous pourrez y effectuer n'importe quel post- traitement (par exemple, validation, logique métier, connexion de l'utilisateur, etc.).
S'il y a des erreurs, vous souhaitez normalement renvoyer la demande à la même page et afficher les erreurs à côté des champs de saisie, etc. Vous pouvez utiliser le RequestDispatcher
pour cela.
Si a POST
réussit, vous voulez normalement rediriger la demande, de sorte que la demande ne soit pas resoumise lorsque l'utilisateur actualise la demande (par exemple en appuyant sur F5 ou en revenant 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.
}
Une redirection demande donc au client de lancer une nouvelle GET
requête sur l'URL donnée. L'actualisation de la demande actualiserait alors uniquement la demande redirigée et non la demande initiale. Cela évitera les «doubles soumissions», la confusion et les mauvaises expériences utilisateur. Ceci est également appelé le POST-Redirect-GET
modèle .
L' RequestDispatcher
interface vous permet de faire une sendRedirect()
redirection / inclusion côté serveur alors qu'une redirection côté client. Dans une redirection côté client, le serveur renverra un code d'état HTTP de 302
(redirection temporaire) qui oblige le navigateur Web à émettre une toute nouvelle GET
requête HTTP pour le contenu à l'emplacement redirigé. En revanche, lors de l'utilisation de l' RequestDispatcher
interface, l'inclusion / transmission vers la nouvelle ressource est entièrement gérée côté serveur.
forward
pas une redirection.
La principale différence importante entre les méthodes forward () et sendRedirect () est que dans le cas de forward (), la redirection se produit à l'extrémité du serveur et n'est pas visible pour le client, mais dans le cas de sendRedirect (), la redirection se produit à l'extrémité du client et elle est visible au client.
L'une ou l'autre de ces méthodes peut être «meilleure», c'est-à-dire 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, vous créez donc une petite incohérence.
Une redirection côté client est plus polyvalente dans la mesure où elle peut vous envoyer vers un serveur complètement différent, ou changer le protocole (par exemple de HTTP à HTTPS), ou les deux. Et le navigateur est conscient de la nouvelle URL. Mais il faut un aller-retour supplémentaire entre le serveur et le client.
SendRedirect()
recherchera le contenu entre les serveurs. il est lent car il doit intimer le navigateur en envoyant l'URL du contenu. alors le navigateur créera une nouvelle demande pour le contenu dans le même serveur ou dans un autre.
RquestDispatcher
est pour rechercher le contenu dans le serveur, je pense. c'est le processus côté serveur et il est plus rapide que la SendRedirect()
méthode. mais le fait est qu'il n'intimera pas le navigateur dans quel serveur il recherche la date ou le contenu requis, ni ne demandera au navigateur de modifier l'URL dans l'onglet URL. donc cela ne cause que peu d'inconvénients à l'utilisateur.
La redirection technique doit être utilisée si nous devons transférer le contrôle vers un domaine différent ou pour réaliser la séparation des tâches.
Par exemple, dans l'application de paiement, nous effectuons d'abord PaymentProcess, puis nous redirigeons vers displayPaymentInfo. Si le client actualise le navigateur, seul displayPaymentInfo sera refait et PaymentProcess ne sera pas répété. Mais si nous utilisons forward dans ce scénario, PaymentProcess et displayPaymentInfo seront réexécutés de manière séquentielle, ce qui peut entraîner des données incohérentes.
Pour d'autres scénarios, le transfert est efficace car il est plus rapide que sendRedirect
Request Dispatcher est une interface utilisée pour envoyer la demande ou la réponse d'une ressource Web à une autre ressource Web. Il contient principalement deux méthodes.
request.forward(req,res)
: Cette méthode est utilisée pour transmettre la demande d'une ressource Web à une autre ressource. c'est-à-dire d'une servlet à une autre servlet ou d'une application Web à une autre application Web.
response.include(req,res)
: Cette méthode est utilisée pour inclure la réponse d'un servlet à un autre servlet
REMARQUE: en utilisant Request Dispatcher, nous pouvons transférer ou inclure la demande ou les réponses dans le même serveur.
request.sendRedirect()
: En utilisant cela, nous pouvons transférer ou inclure la demande ou les réponses sur les différents serveurs. Dans ce cas, le client reçoit une indication lors de la redirection de la page, mais dans le processus ci-dessus, le client ne recevra pas d'indication
Différence simplement entre Forward(ServletRequest request, ServletResponse response)
et sendRedirect(String url)
est
vers l'avant():
forward()
méthode est exécutée côté serveur.forward ()
méthode est fournie par le conteneur de servlet.forward()
méthode est plus rapide que la sendRedirect()
méthode.RequestDispatcher
interface.sendRedirect ():
response.sendRedirect("..")
à la page index.jsp du site Web. Mais cela manque les fichiers css et du texte de la page jsp, ce qui entraîne un chargement partiel de la page. Mais lorsque je fais de la page d'accueil du site Web index.jsp, tout fonctionne bien et le chargement de la page est terminé. quel est le problème avec la redirection?