Newsgroup: it.comp.java
Titolo: servlet:  sendRedirect oppuer forward

che vantaggio ho ad crere un dispatcher e fare forward anziche usare
sendRedirect?
finora la differenza che ho trovato è che sendRedirect cambia l'url
sul browser e il referer mentre facendo forward resta l'indirizzo
della servlet
Ciao
Chairam

 writes:
c> che vantaggio ho ad crere un dispatcher e fare forward anziche
c> usare sendRedirect?
c> finora la differenza che ho trovato è che sendRedirect cambia l'url
c> sul browser e il referer mentre facendo forward resta l'indirizzo
c> della servlet
Ma leggersi  la documentazione  :) (O.K. è  in inglese) ?  La redirect
manda  al  client  una  informazione  di redirect,  quindi  il  client
RICHIEDE la nuova pagina.
La forward invece passa la  response ad una nuova servlet che continua
l'elaborazione  prima  di  dare  la  risposta  o  fare  una  ulteriore
forward. Il client non c'entra per niente.
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

forward. Il client non c'entra per niente.
ok ci sono
ho questo problema (uso tomcat)
ho fatto una form di login per un sito, per includerla in alcune
pagine usando una direttiva include
l'idea è questa:
se l'utene è anonimo appare la form con i campi log in e pw
se è autenticato mostra il nome dell'utente
l'idea è: arrivi sulla pagina, qualunque essa sia , ti logghi e ti si
ricarica la pagina mostrandoti che ti sei loggato
ho inizianto usando pagina->servlet->forward, usavo il referer
dell'header per sapere quale pagina chiama per tornarci, ma con
forward il tutto finiva in un bel loop servlet->servlet
per questo sono passato a redirect
ora pero: refere non c'è sempre
qual'è il modo migliore di sapere quale pagina chiama?
... hidden field.. attributo settato nella sessione...
Ciao
Chairam

 writes:
c> l'idea č: arrivi sulla pagina, qualunque essa sia , ti logghi e ti
c> si ricarica la pagina mostrandoti che ti sei loggato
c> ho inizianto usando pagina->servlet->forward, usavo il referer
c> dell'header per sapere quale pagina chiama per tornarci, ma con
c> forward il tutto finiva in un bel loop servlet->servlet per questo
c> sono passato a redirect
Sicuro che il problema sia legato al meccanismo della forward ?
A naso sembra che non venga riconosciuto il login come avvenuto.
c> ora pero: refere non c'č sempre
E' infatti opzionale.
c> qual'č il modo migliore di sapere
c> quale pagina chiama?  ... hidden field.. attributo settato nella
c> sessione...
Una qualsiasi servlet  che non ha fatto output (se  non erro) puň fare
la forward dopo aver settato un attributo nella request. 


 sendRedirect?
Il redirect restituisce un header al browser il quale ripete un'altra 
richiesta all'url indicato.
Il forward è invece un metodo per passare internamente il controllo 
della richesta corrente un'altra servlet/JSP.

la forward dopo aver settato un attributo nella request. 
attributo... non capisco quale attributo
in ogni caso ho risolto così:
al caricamento la jsp mette un attributo in session che contiene
l'indirizzo della pagina che chiama la servlet
ora penso che sia sbaglito: crea dei casini se l'utente naviga 2
pagine del sito in due finestre del browser e la session è comune
all'utente sarà meglio mettere l'attributo in request.
Ciao!!
Chairam


induco che:
con il forward il browser interpreta quello che gli arriva come
risposta alla GET o POST che ha fatto, per questo tiene come indirizzo
nella barra degli indirizzi quell del GET o POST e il forward è
conosciuto solo dal server e tutti sono felici.
Se è così ho capito
Grazie
Ciao!
Chairam

 ha scritto nel messaggio 
news:ptgh82p8e538pk1vs...@4ax.com...

Oltre a quello che ti hanno gia' detto tieni presente che dopo un forward se 
fai il refresh della pagina  viene rieseguita la servlet. Mentre con il 
redirect no.

all'utente sarà meglio mettere l'attributo in request.
ulteriore rettifica riguardo l'uso di request
ho scritto credevo che attaccando attributi a request nella
generazione della jsp restassero attaccati al request che arrivava
alla servlet chiamata dalla jsp
sbagliato
(ma allora perchè posso fare setAttribute su request?
ho rispolto mettendo nella jsp un hidden field
penso che questa  quest sia finita :-)
Ciao!!
Chairam


request1
JSP -> browser
request2
browser --> servlet
perche' mai nella request2 dovrebbero rimanere gli attributi della request1? 

 JSP -> browser
scusa:
request1
browser->...->JSP 



si alla fine ho relizzato
tnx
Ciao
Rob


Metodo SetAttribute previsto dall'interfaccia 
javax.servlet.ServletRequest
c> in ogni caso ho risolto così: al caricamento la jsp mette un
c> attributo in session che contiene l'indirizzo della pagina che
c> chiama la servlet
c> ora penso che sia sbaglito: crea dei casini se l'utente naviga 2
c> pagine del sito in due finestre del browser e la session è comune
c> all'utente sarà meglio mettere l'attributo in request.
Usando un attributo  nella request la jsp può mettere  l'url con cui è
stata richiata  in questo attributo,  fare una forward al  processo di
autenticazione che  ricupera l'url di  ritorno dal parametro.  Se devi
passare ancora per il browser, non  mi pare ci siano grossi problemi a
mettere l'url di ritorno in  un hidden field del form, ma bisognerebbe
vedere meglio l'architettura. 
Invece dell'url,  se la cosa ti  secca, puoi far girare  un id casuale
che ti permetta di ricuperare da una qualche parte l'URL, e il qualche
parte potrebbe  essere ancora  la sessione dato  che nel caso  del tuo
malfunzionamento avresti comunque i  due valori associati a due chiavi
diverse in sessione.


diverse in sessione.
buona idea, allo stato attuale aggiungerebbe complessità non
necessaria. L'architettura com'è impostata ora funziona bene
Grazie!!
Ciao
Chairam

 writes:
c> servizio di autenticazione - su un'altra macchina
c> -disponibile ad altri programmi ...
Ovvero singled signo on... Avere un buon metodo è comodo :)
