Steven J. Owens wrote:
>> "Another nuance, which I find comes in handy quite often, is that
>> responding to a form submit with a redirect will prevent the browser
>> from offering to re-post the parameters for the user."
On Fri, Apr 16, 2004 at 10:30:59AM +0530, [EMAIL PROTECTED] wrote:
> Even I observed this..This is very much useful..But, I dont
> understand why the form values are not updated in case of
> redirect.Can you please throw some light on this??
I'm not sure what "form values are not updated" means, but I will
point out that redirects are restricted to GET requests only. If you
wanted to include parameters to be passed along in the redirect, you'd
have to encode them into a query string and append that to the URL
you're redirecting to, i.e.:
http://www.example.com/redirectarget?foo=bar&baz=bat
You cannot redirect to a POST (the browsers don't support it), so
if the redirecttarget is expecting only a POST, this will not work. It
has to have doGet() implemented to get the query string parameters.
If the redirect target URL is on the same servlet engine, you can
store the parameters in a server-side HTTP session attribute in the
servlet engine before you redirect, and in the redirect target
servlet, pull the parameters out of the session.
e.g.
servlet1:
request.getSession().setAttribute("foo", "bar") ;
response.sendRedirect("servlet2") ;
servlet2:
String fooparam = request.getSession().getAttribute("foo") ;
This is not strictly safe. The user could conceivably have two
browser windows open and be clicking on a button in browser window A
that modifies the session attribute, while browser window B is still
loading the redirect target which will display the session attribute.
But in practice I have never seen that become a real problem. Most
users who figure out that they can use two browser windows at once
seem to get the idea that both windows are affecting the same
server-side session.
I strongly, strongly recommend that anybody working on web
applications should learn the basics of the HTTP protocol.
Specifically, I recommend that you get a packet sniffer, or a logging
proxy, to monitor the traffic between your browser and your server.
At the very least, use Mozilla Firefox and use the LiveHttpHeaders
plug-in. You will learn a ton about how your browser and server talk
to each other. This will make the rest of the picture make a lot more
sense.
--
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
