Re: request.setAttribute(...) versus session.setAttribute(...)

From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 11/08/04 

Date: Mon, 08 Nov 2004 09:00:36 -0500

johnangxun wrote:

> to: john C. Bollinger&q;
>
>
>>As Sudsy was pointing out, you also need to watch out
>>for caching behavior. User agents (generally browsers), > proxies, and
>
> web servers all may cache responses under
>
>>certain circumstances. All may cause trouble, but the
>>most likely to do so are user agents. For instance,
>>when a human user clicks the *"Back"* button on his
>>browser's toolbar, he will generally get a cached
>>version of the previously visited page instead of
>>causing a new request to be issued for that page. This > may be
>
> different from what he would get by reissuing the > same request by which
> the cached page was originally
>
>>fetched.
>
>
> Can u explain more about this. I not clear to it. Thanks.

(*) User clicks hyperlink in page (1) displayed in browser window.

(*) Browser makes HTTP request for document associated with the link's URL

(*) Server prepares and sends a response, possibly changing session or
application state while so doing

(*) Browser renders the content of the HTTP response (page 2), and
caches a copy of it.

(*) User clicks a submit button or link in page 2

(*) Browser makes HTTP request for document associated with the link's
URL or the form's action

(*) Server prepares and sends a response, possibly changing session or
application state while so doing

(*) Browser renders the content of the HTTP response (page 3), and
caches a copy of it.

(*) User clicks his browser's "back" button

(*) Browser [maybe] displays page 2 _from cache_, exactly as it was
originally received. Depending on the application, this differ from the
result of a new request for page 2's URL.

> Recently I deal with the form processing. I have one form, user will key
> in a lot of the field. After human user finish key in, the enter the
> submit, the *confirmation page* will display, which show all the data key
> in by user. If human user need to change the information, their can click
> *back* button to rekey in again.

No, they can't.

> But if I click the back button, all the information is the submit
> form(first form) will lost.

That's why they can't.

> So is it any way to solve it. If I use the session.setAttribute at the
> submit form(first page) will it help?

Surely it depends on what attribute you set to what value, when, and on
how your application thereafter uses the the attribute.

If you want to provide a robust means for the user to update data they
already submitted to the server then it must operate by means of the
user sending a _new HTTP request_, not by their use of the browser's
"back" button. The user's current responses must be remembered in some
way; this could be in one or more session attributes or in the
confirmation page itself. The data entry page would be populated (on
the server side) with whatever remembered information the server has to
work with. This is all very high level. The details of how you might
accomplish such behavior are quite varied.

John Bollinger
jobollin@indiana.edu

Quantcast