Solve the Problem of repeated jsp submission

After reading this online, there are several methods: 1. Add this code to the HEAD area on your table sheet page: <META HTTP-EQUIV = "pragma" CONTENT = "no-cache"> <META HTTP-EQUIV = "Cache-Control" CONTENT = "no-cache, must-revalidate "> <META HTTP-EQUIV =" expires "CONTENT =" Wed, 26 Feb 1997 08:21:57 GMT "> 2 generate a token to be saved in the user session, add a hidden domain in the form to display the value of this token. After the form is submitted, a new token is generated and the token submitted by the user is compared with the token in the session, if they are the same, submit them again. 3. Use Response in your server-side control code. redirect ("selfPage") statement. However, this method is not used in most cases. There are many other methods... 4 <input type = "button" value = "Submit" onclick = "this. disabled = true; this. form. submit () "> 5 add a hidden field <input type =" hidden "name =" url "value = <% = request. getRequestURL () %> In Your serverlet, add the following statement: String url = request. getParameter ("url"); response. sendRedirect (url); I usually use this method to return the JSP page, I don't quite understand what you mean by refresh. 6. ajax does not need to submit again. 7. In Web development, how can I solve the problem of preventing the browser refresh key from causing repeated system operations? Redirection can solve the problem of repeated data submission caused by PAGE refresh. We can use redirection to solve this problem. However, in the struts action, mapping. findword (); by default, you can find the page to jump to in the project folder. How can this problem be solved? Modify the struts-config.xml file, there is a redirect retargeting attribute in action, struts default is false, add this attribute, change to true, write the absolute or relative address of the page to jump to in forword as follows: <action-mappings> <action attribute = "newsActionForm" name = "newsActionForm" input = "/addnews. jsp "path ="/newsAction "parameter =" method "scope =" request "type =" com. yongtree. news. action. newsAction "> <forward name =" list "path ="/listnews. jsp "redirect =" true "> </forward> <forward name =" error" Path = "/addnews. jsp"> </forward> </action-mappings> repeated submission, refresh, back-off prevention, and solution 1. Preface you will see such a problem in any professional BBS. Even if you Google it, you will find that many people are paying attention to and asking, however, the solutions provided by everyone vary widely (Some people advocate using scripts to solve the problem; some want to redirect to other pages; some want to raise the problem to the Token perspective) why is there such a big difference? II. Problem scenarios first, we should first understand why we should solve such problems? Or what is the ideal scenario? (It seems that only one person can ask and no one can explain) 1. Repeated submission and refresh are used to solve the problem of Repeated Records in the system. That is to say, a person submits a record multiple times (why? Maybe you are idle and have nothing to do. The most likely reason is that you do not know whether your submission results have been executed ?!). However, when such a problem occurs, it is not necessary to handle it. It depends on the type of the system you are developing. For example, if you take over a resource management system, the system itself is not allowed to have "repeated" records from the perspective of requirements. under the constraints of such requirements, executing repeated commit operations will only lead to "business-level exceptions", and it is impossible to execute the operation successfully, so it does not matter to avoid unavoidable problems. 2. The scenario of preventing rollback understands the scenarios of repeated refresh and repeated submission. Let's take a look at the reason for the "Preventing rollback" operation? For example, if you are developing a voting system, there are many steps and there are links between these steps. For example, the first step will send some information to the second step, step 2 caches the information and sends the information to Step 3 ..... Wait. If the user is in step 3, imagine a naughty user clicking the back button, and the page of step 2 appears, he makes another modification or submits it again and goes to the next step (that is, the third step). The error will be generated here ?! What are the errors? This operation directly causes the loss of the first step information! (If such information is stored by Request, you can store it in a Session or a larger context, but this is not a good idea! For information storage, we will discuss this issue in detail next time.) 3. Of course, many systems (for example, the ticket booking system itself allows individuals to repeat tickets on demand) must avoid repeated refresh, repeat submission, and prevent rollback, however, even such problems need to be differentiated between how to handle and where to handle them (the Internet only tells you how to handle them, but seldom distinguishes where to handle them ), obviously, the processing method is nothing more than client or server, and the processing method is different for different locations, but one thing must be stated in advance: any client (especially B/S) is not trusted, and the best and most appropriate is the server-side processing method. Client processing: In the face of the client, we can use the Javascript script to solve the problem, as shown in the following 1. Refresh and submit repeatedly. Ways One: Set a variable that can only be submitted once. <Script language = "javascript"> var checkSubmitFlg = false; function checkSubmit () {if (checkSubmitFlg = true) {return false;} checkSubmitFlg = true; return true;} document. ondblclick = function docondblclick () {window. event. returnValue = false;} document. onclick = function doconclick () {if (checkSubmitFlg) {window. event. returnValue = false ;}}</script>