Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@www.apache.org Received: (qmail 34291 invoked from network); 6 Oct 2003 20:39:22 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 6 Oct 2003 20:39:22 -0000 Received: (qmail 56692 invoked by uid 500); 6 Oct 2003 20:38:45 -0000 Delivered-To: apmail-jakarta-struts-user-archive@jakarta.apache.org Received: (qmail 56641 invoked by uid 500); 6 Oct 2003 20:38:44 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 56568 invoked from network); 6 Oct 2003 20:38:43 -0000 Received: from unknown (HELO darksleep.com) (192.204.202.251) by daedalus.apache.org with SMTP; 6 Oct 2003 20:38:43 -0000 Received: by darksleep.com (Postfix, from userid 1009) id 72C183CD2B; Mon, 6 Oct 2003 16:38:44 -0400 (EDT) Date: Mon, 6 Oct 2003 16:38:44 -0400 From: "Steven J. Owens" To: Struts Users Mailing List Subject: Re: What's the best strategy to handle this kind of thread issues? Message-ID: <20031006203844.GD8854@darksleep.com> Reply-To: puff@darksleep.com References: <002101c3776b$80d47880$6400a8c0@carrier> <20030910100210.V52597@minotaur.apache.org> <001e01c377cc$3dd7c350$6400a8c0@carrier> <20030910150945.U27715@minotaur.apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030910150945.U27715@minotaur.apache.org> User-Agent: Mutt/1.4i Sender: Steven J.Owens X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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 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