struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven J. Owens" <puffm...@darksleep.com>
Subject Re: What's the best strategy to handle this kind of thread issues?
Date Mon, 06 Oct 2003 20:38:44 GMT
On Wed, Sep 10, 2003 at 03:17:35PM -0700, Craig R. McClanahan wrote:
> > What we found in IE 6.0 sp1 is that end users do not have to press
> > STOP and then manually trigger a second request. They could just
> > press buttons in a web form and trigger different requests to the
> > server. Is this a bug in IE 6.0? (The scenario (a) looks correct
> > in IE 5.0)
> 
> I suppose that behavior is similar on lots of other browsers -- I
> just tried it on Mozilla 1.4 and it does the same thing; as far as
> the browser is concerned, it just stops paying attention to the
> original request and starts paying attention to the new one.

     This is pretty standard behavior, IIRC it dates at least as far
back as early 1998, late 1997.  Somewhere in there it became possible
to click on a button in a page, then click on another button before
the first submit completed.  Any subsequent request that targeeds the
same window or frame killed the first request (from the browser's
point of view).  When I was playing with this stuff, on both IE4 and
Netscape 4.x, it tended to just kill the ongoing request as soon as
you started another one.  You still had no way of knowing how far
along the first request was.  

     I don't remember distinctly testing this on earlier versions (at
the time I testing against IE3 and IE4, and NS2, NS3, NS4), but I
wouldn't be surprised if it goes all the way back to the point where
browsers first started being less all-or-nothing with page rendering
The earliest browsers didn't display *anything* until the entire page
was rendered and all of the images fetched.  Netscape 2.0 introduced
<IMG> width/height attributes to allow the browser to render the page
with appropriately-sized blank spaces and display the general content
while it was still downloading images.

> All you can really do is detect that the situation happened, synchronize
> against multithread race conditions, and make sure that the second
> response sends back what you want (since the user isn't going to see the
> first response).

     The standard advice when building web apps is to have your
server-side code check for double-submits, typically by looking at the
values submitted, i.e. did Jane Q Public really want to place two
consecutive orders for a single copy of the latest Danielle Steele
novel?

     Sometimes you do slightly clever things with inserting a hidden
UUID in each form, and keeping track of which UUIDs have been
submitted.  I wonder if this could be abstracted enough to make a
useful generic check (akin to the JSESSIONID)?

     The other standard tactic is to go to insane lengths to prevent
the user from ever actually seeing the same page twice, i.e. defeat
caching. This includes not just HTTP headers and META tags (all of
which are only partially reliable) but crazy stuff like putting a
unique string in each URL link to short-circuit browser caching.  

     Even that won't always work, since most browsers, if you use the
back/forward button to go to a page that was the result of a post,
will offer to re-post the arguments (and if you use the right headers,
will refuse to re-display the page without re-posting).  The
work-around for this is to never have your posted-to servlets actually
respond with a page.  Instead, have them send a client-side redirect
back to the browser, to another JSP or servlet, which loads any data
from the user's servelt session.

     Speaking of servlet session, one thing I've been wondering
recently is why the Principal is only accessible via the
HttpServletRequest, and not from the session.  Any idea of the
rationale behind that decision?

-- 
Steven J. Owens
puff@darksleep.com

"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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message