Hi, We have been looking at the implementation of an out of order request detection mechanism very similar to the one built in to Struts. For a single frame application, this works as follows, upon reception of a request:
1. The action object extracts a token (if any) from the session, and stores it as 'the old token'. 2. The action object then generates a new token to identify the current request, and places this token in the session. 3. The action object compares the token it extracts from the current request (if any) with 'the old token', that previously in the session. They should match. If they don't, then the current request is classified as an 'out of order' or duplicate request. The action object can change the request's action to something else, if it is thought that duplicating the action in question might be harmful. 4. The request is forwarded to the corresponding JSP page. 5. Code on the JSP page extracts the token from the session, and makes it the value of a hidden form field. 6. If the page and its form are subsequently submitted, the token value will be submitted as part of the request. The "loop" begins again from step 1. The token submitted here in step 6 will be compared in step 3. This seems to work well for detecting duplicate requests resulting from the user hitting the reload/back or forward buttons on the browser. Then we tried to apply the same approach to a framed application. The problem with a framed application is that each user action can result in a number of requests, hence we can't assume that an in order request's token value should match the last one generated but one. A colleague came up with a solution for this. Instead of just getting the pages to submit whatever value they pick up from the session at time of rendering, we get each page to store the value extracted from the session at the time of rendering in a JavaScript global variable, or one on the top level window. Then, at time of submission, the page picks up this value from the JavaScript, and submits this. The rest of the process should work as before. The important point here is that this JavaScript variable is shared by all requests, and thus, we effectively end up with one token identifying each user action, rather than one for each request. All of the requests from a single user action should be submitted with the same token value. This seemed to work fine in both Internet Explorer 6.0 and Netscape 6.2. Then I discovered one problem. In a particular test case, I would get the application to carry out a Struts forward action to the page containing the frameset containing the pages in question. Then, I would invoke an action on one of those pages to see whether the application thought such a request was a duplicate or not. It should not. Generally it did not. However, about 1 in every 10 times, with Internet Explorer only, the tokens would not match, and it would come up with a "false positive". It would classify the first instance of a request as a duplicate. Has anyone else seen this sort of behavior? It seems to be something peculiar to the combination of a Struts forward to a frameset followed by the action in question, when using IE only. Is is possible that this is occuring due to some sort of race condition? Any ideas welcome. Thanks, Vaughan. ___________________________________________________ Vaughan Jackson Development Tumbleweed Communications [EMAIL PROTECTED] / +1 (650) 216 2532 ___________________________________________________ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
