RequestDispatcher.forward () vs HttpServletResponse.sendRedirect ()


Risposte:


106

requestDispatcher - metodo forward ()

  1. Quando utilizziamo il forwardmetodo, la richiesta viene trasferita a un'altra risorsa all'interno dello stesso server per un'ulteriore elaborazione.

  2. Nel caso di forward, il contenitore web gestisce internamente tutte le elaborazioni e il client o il browser non sono coinvolti.

  3. Quando forwardviene chiamato requestDispatchersull'oggetto, passiamo gli oggetti richiesta e risposta, quindi il nostro vecchio oggetto richiesta è presente sulla nuova risorsa che elaborerà la nostra richiesta.

  4. Visivamente, non siamo in grado di vedere l'indirizzo inoltrato, è trasparente.

  5. L'uso del forward()metodo è più veloce di sendRedirect.

  6. Quando reindirizziamo usando forward e vogliamo usare gli stessi dati in una nuova risorsa, possiamo usarli request.setAttribute()dato che abbiamo un oggetto richiesta disponibile.

sendRedirect

  1. In caso di sendRedirect, la richiesta viene trasferita a un'altra risorsa, a un dominio diverso o a un server diverso per un'ulteriore elaborazione.

  2. Quando si utilizza sendRedirect, il contenitore trasferisce la richiesta al client o al browser, quindi l'URL fornito all'interno del sendRedirectmetodo è visibile come nuova richiesta al client.

  3. In caso di sendRedirectchiamata, i vecchi oggetti richiesta e risposta vengono persi perché vengono trattati come nuova richiesta dal browser.

  4. Nella barra degli indirizzi, possiamo vedere il nuovo indirizzo reindirizzato. Non è trasparente.

  5. sendRedirectè più lento perché è richiesto un round trip aggiuntivo, perché viene creata una richiesta completamente nuova e il vecchio oggetto richiesta viene perso. Sono necessarie due richieste del browser.

  6. Ma in sendRedirect, se vogliamo utilizzare gli stessi dati per una nuova risorsa, dobbiamo memorizzare i dati in sessione o passare insieme all'URL.

Qual è buono?

Dipende dallo scenario per il quale il metodo è più utile.

Se si desidera che il controllo venga trasferito a un nuovo server o contesto e venga trattato come un'attività completamente nuova, allora si opta per sendRedirect. In genere, è necessario utilizzare un forward se l'operazione può essere ripetuta in sicurezza al ricaricamento del browser della pagina Web e non influirà sul risultato.

fonte


161

Nel mondo dello sviluppo web, il termine "reindirizzamento" è l'atto di inviare al client una risposta HTTP vuota con solo Locationun'intestazione contenente il nuovo URL a cui il client deve inviare una nuova richiesta GET. Quindi in poche parole:

  • Il client invia una richiesta HTTP a some.jsp.
  • Il server invia una risposta HTTP con l' Location: other.jspintestazione
  • Il client invia una richiesta HTTP a other.jsp(questo si riflette nella barra degli indirizzi del browser!)
  • Il server invia una risposta HTTP con il contenuto di other.jsp.

Puoi seguirlo con il set di strumenti per sviluppatori integrato / addon del browser web. Premi F12 in Chrome / IE9 / Firebug e controlla la sezione "Rete" per vederlo.

Esattamente quanto sopra si ottiene da sendRedirect("other.jsp"). Il RequestDispatcher#forward()non invia un reindirizzamento. Invece, utilizza il contenuto della pagina di destinazione come risposta HTTP.

  • Il client invia una richiesta HTTP a some.jsp.
  • Il server invia una risposta HTTP con il contenuto di other.jsp.

Tuttavia, poiché la richiesta HTTP originale doveva avvenire some.jsp, l'URL nella barra degli indirizzi del browser rimane invariato. Inoltre, tutti gli attributi di richiesta impostati nel controller dietro some.jspsaranno disponibili in other.jsp. Ciò non accade durante un reindirizzamento perché in pratica stai forzando il client a creare una nuova richiesta HTTP other.jsp, eliminando la richiesta originale some.jspincludendo tutti i suoi attributi.


Il RequestDispatcherè estremamente utile nel paradigma MVC e / o quando si desidera nascondere JSP di accesso diretto. È possibile inserire i JSP nella /WEB-INFcartella e utilizzare a Servletche controlla, preprocessa e postprocessa le richieste. I JSP nella /WEB-INFcartella non sono direttamente accessibili tramite URL, ma Servletpossono accedervi utilizzando RequestDispatcher#forward().

È possibile ad esempio avere un file JSP in /WEB-INF/login.jsped una LoginServletche viene mappato su un url-patterndi /login. Quando si invoca http://example.com/context/login, verrà richiamato il servlet doGet(). Puoi eseguire qualsiasi operazione di pre- elaborazione e infine inoltrare la richiesta come:

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

Quando invii un modulo, normalmente desideri utilizzare POST:

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

In questo modo doPost()verranno invocati i servlet e potrai eseguire qualsiasi operazione di post- elaborazione (ad esempio convalida, logica aziendale, login dell'utente, ecc.).

Se sono presenti errori, normalmente si desidera inoltrare la richiesta alla stessa pagina e visualizzare gli errori lì accanto ai campi di input e così via. Puoi usare RequestDispatcherper questo.

Se a ha POSTsuccesso, normalmente si desidera reindirizzare la richiesta, in modo che la richiesta non venga reinviata quando l'utente aggiorna la richiesta (es. Premendo F5 o navigando indietro nella cronologia).

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

Un reindirizzamento indica quindi al client di attivare una nuova GETrichiesta sull'URL specificato. L'aggiornamento della richiesta aggiorna quindi solo la richiesta reindirizzata e non la richiesta iniziale. Ciò eviterà "doppi invii", confusione e cattive esperienze utente. Questo è anche chiamato il POST-Redirect-GETmodello .

Guarda anche:


Mentre eseguo il reindirizzamento da un servlet a una pagina jsp, la pagina jsp viene caricata parzialmente, come in stackoverflow.com/questions/12337624/… . Volevo che la prima cosa da eseguire quando qualcuno premeva foo.com fosse il servlet. Dal servlet faccio un response.sendRedirect("..")alla pagina index.jsp del sito. Ma questo perde i file css e del testo dalla pagina jsp, portando a un caricamento parziale della pagina. Ma quando creo index.jsp nella pagina di benvenuto del sito web, tutto funziona correttamente e la pagina viene caricata completa. cosa c'è di sbagliato nel reindirizzamento?
saplingPro

20

L' RequestDispatcherinterfaccia consente di eseguire un forward / include lato server mentre sendRedirect()esegue un reindirizzamento lato client. In un reindirizzamento lato client, il server invierà un codice di stato HTTP di 302(reindirizzamento temporaneo) che fa sì che il browser web emetta una nuova GETrichiesta HTTP per il contenuto nella posizione reindirizzata. Al contrario, quando si utilizza l' RequestDispatcherinterfaccia, l'inclusione / inoltro della nuova risorsa viene gestito interamente dal lato server.


E quest'ultimo in realtà forwardnon è reindirizzamento.
Adeel Ansari

5

La principale differenza importante tra il metodo forward () e sendRedirect () è che in caso di forward (), il reindirizzamento avviene all'estremità del server e non è visibile al client, ma in caso di sendRedirect (), il reindirizzamento avviene all'estremità del client ed è visibile al cliente.

inserisci qui la descrizione dell'immagine


2
Un'immagine vale più di mille parole :)
Eugen Labun

4

Ciascuno di questi metodi può essere "migliore", cioè più adatto, a seconda di ciò che si desidera fare.

Un reindirizzamento lato server è più veloce nella misura in cui ottieni i dati da una pagina diversa senza fare un viaggio di andata e ritorno al browser. Ma l'URL visualizzato nel browser è ancora l'indirizzo originale, quindi stai creando una piccola incoerenza lì.

Un reindirizzamento lato client è più versatile in quanto può inviarti a un server completamente diverso o cambiare il protocollo (ad esempio da HTTP a HTTPS) o entrambi. E il browser è a conoscenza del nuovo URL. Ma ci vuole un ulteriore avanti e indietro tra server e client.


2
Questo segmento qui non è menzionato abbastanza sul Web: "o cambia il protocollo (ad es. Da HTTP a HTTPS), o entrambi"
Perdomoff

3

SendRedirect()cercherà il contenuto tra i server. è lento perché deve intimare il browser inviando l'URL del contenuto. quindi il browser creerà una nuova richiesta per il contenuto all'interno dello stesso server o in un altro.

RquestDispatcherè per la ricerca del contenuto all'interno del server, penso. è il processo lato server ed è più veloce rispetto al SendRedirect()metodo. ma il fatto è che non indicherà il browser in cui server sta cercando la data o il contenuto richiesti, né chiederà al browser di cambiare l'URL nella scheda URL. quindi causa poco disagio all'utente.


1

Tecnicamente, il reindirizzamento dovrebbe essere utilizzato se è necessario trasferire il controllo a un dominio diverso o per ottenere la separazione delle attività.

Ad esempio, nell'applicazione di pagamento eseguiamo prima il PaymentProcess e poi reindirizziamo a displayPaymentInfo. Se il client aggiorna il browser, verrà eseguito nuovamente solo displayPaymentInfo e PaymentProcess non verrà ripetuto. Ma se utilizziamo forward in questo scenario, sia PaymentProcess che displayPaymentInfo verranno rieseguiti in sequenza, il che potrebbe generare dati incoerenti.

Per altri scenari, forward è efficiente da usare poiché è più veloce di sendRedirect


0

Request Dispatcher è un'interfaccia che viene utilizzata per inviare la richiesta o la risposta dalla risorsa web a un'altra risorsa web. Contiene principalmente due metodi.

  1. request.forward(req,res): Questo metodo viene utilizzato per inoltrare la richiesta da una risorsa Web a un'altra risorsa. cioè da un servlet a un altro servlet o da un'applicazione web a un'altra applicazione web.

  2. response.include(req,res): Questo metodo viene utilizzato per includere la risposta di un servlet a un altro servlet

NOTA: utilizzando Request Dispatcher possiamo inoltrare o includere la richiesta o le risposte nello stesso server.

request.sendRedirect(): Usando questo possiamo inoltrare o includere la richiesta o le risposte attraverso i diversi server. In questo il client riceve un'intimazione durante il reindirizzamento della pagina, ma nel processo sopra il client non riceverà alcuna intimazione


-1

Semplicemente differenza tra Forward(ServletRequest request, ServletResponse response)ed sendRedirect(String url)è

inoltrare():

  1. Il forward()metodo viene eseguito sul lato server.
  2. La richiesta viene trasferita ad un'altra risorsa all'interno dello stesso server.
  3. Non dipende dal protocollo di richiesta del client poiché il forward ()metodo è fornito dal contenitore servlet.
  4. La richiesta è condivisa dalla risorsa di destinazione.
  5. In questo metodo viene utilizzata solo una chiamata.
  6. Può essere utilizzato all'interno del server.
  7. Non possiamo vedere il messaggio inoltrato, è trasparente.
  8. Il forward()metodo è più veloce del sendRedirect()metodo.
  9. È dichiarato RequestDispatchernell'interfaccia.

sendRedirect ():

  1. Il metodo sendRedirect () viene eseguito sul lato client.
  2. La richiesta viene trasferita su un'altra risorsa su un server diverso.
  3. Il metodo sendRedirect () viene fornito sotto HTTP, quindi può essere utilizzato solo con i client HTTP.
  4. Viene creata una nuova richiesta per la risorsa di destinazione.
  5. Vengono utilizzate due chiamate di richiesta e di risposta.
  6. Può essere utilizzato all'interno e all'esterno del server.
  7. Possiamo vedere l'indirizzo reindirizzato, non è trasparente.
  8. Il metodo sendRedirect () è più lento perché quando viene creata una nuova richiesta, il vecchio oggetto richiesta viene perso.
  9. È dichiarato in HttpServletResponse.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.