重复提交、重复刷新、防止后退的问题以及处理方式分析
作者：佚名
字体：[ ] 来源：互联网 时间：02-08 21:34:54
你在任何一个比较专业的BBS都会看到这样的问题，即使你Google一下，也会发现有很多的人在关注和询问，但大家给出的解决方法却都是千差万别。
一。前言 你在任何一个比较专业的BBS都会看到这样的问题，即使你Google一下，也会发现有很多的人在关注和询问，但大家给出的解决方法却都是千差万别，（有的人主张采用脚本来解决;有的则想重定向到别的页面;有的则将此问题提升到Token的角度）为什么会有如此大的差异呢？ 二。问题场景 首先，我们应该先了解为什么要处理这样的问题？或者专业一点就是它适合的场景是什么？（似乎只有人来问没有人来解释） 1。重复提交、重复刷新的场景 重复提交、重复刷新都是来解决系统重复记录的问题。也就是说某个人在多次的提交某条记录（为什么？也许是闲了没有事情干的;最有可能是用户根本就不知道自己的提交结果是否已经执行了？！）。 但出现了这样的问题并不见得就必须处理，要看你所开发的系统的类别而定。比如你接手的是某个资源管理系统，系统本身从需求的角度根本就不允许出现&重复&的记录，在这样需求的约束条件下，去执行重复的提交动作只会引发&业务级异常&的产生，根本就不可能执行成功也就无所谓避免不避免的问题了。 2。防止后退的场景 了解了重复刷新、重复提交的场景，我们来了解一下&防止后退&操作的原因是什么？比如你在开发某个投票系统，它有很多的步骤，并且这些步骤之间是有联系的，比如第一步会将某些信息发送给第二步，第二步缓存了这些信息，同时将自身的信息发送给了第三步。。。。。等等，如果此时用户处在第三步骤下，我们想象一下某个淘气用户的用户点击了后退按钮，此时屏幕出现了第二步骤的页面，他再次的修改或者再次的提交，进入到下一个步骤（也就是第三步骤），错误就会在此产生？！什么错误呢？最为典型的就是这样的操作直接导致了对于第一个步骤信息的丢失！（如果这样的信息是依靠Request存放的话，当然你可以存放在Session或者更大的上下文环境中，但这不是个好主意！关于信息存放的问题，下次在就这个问题详细的讨论） 三。如何处理的问题 当然很多的系统（比如订票系统从需求上本身是允许个人重复订票的）是必须要避免重复刷新、重复提交、以及防止后退的问题的，但即使是这样的问题，也要区分如何处理以及在哪里处理的（网上只是告诉你如何处理，但很少去区分在哪里处理的），显然处理的方式无非是客户端或者服务器端两种，而面对不同的位置处理的方式也是不同的，但有一点要事先声明：任何客户端（尤其是B/S端）的处理都是不可信任的，最好的也是最应该的是服务器端的处理方法。 客户端处理： 面对客户端我们可以使用Javascript脚本来解决，如下 1。重复刷新、重复提交 Ways One：设置一个变量，只允许提交一次。 代码如下: &script language="javascript"& var checkSubmitFlg = function checkSubmit() { if (checkSubmitFlg == true) {
} checkSubmitFlg =
} document.ondblclick = function docondblclick() { window.event.returnValue = } document.onclick = function doc { if (checkSubmitFlg) { window.event.returnValue = } } &/script& &html:form action="myAction.do" method="post" onsubmit="return checkSubmit();"& Way Two : 将提交按钮或者image置为disable &html:form action="myAction.do" method="post" onsubmit=" getElById_r('submitInput').disabled ="& &html:image styleId="submitInput" src="images/ok_b.gif" border="0" /& &/html:form& 2。防止用户后退 这里的方法是千姿百态，有的是更改浏览器的历史纪录的，比如使用window.history.forward()方法;有的是&用新页面的URL替换当前的历史纪录，这样浏览历史记录中就只有一个页面，后退按钮永远不会变为可用。&比如使用javascript:location.replace(this.href); event.returnValue= 2.服务器端的处理（这里只说Struts框架的处理） 利用同步令牌（Token）机制来解决Web应用中重复提交的问题，Struts也给出了一个参考实现。 基本原理： 服务器端在处理到达的请求之前，会将请求中包含的令牌值与保存在当前用户会话中的令牌值进行比较， 看是否匹配。在处理完该请求后，且在答复发送给客户端之前，将会产生一个新的令牌，该令牌除传给 客户端以外，也会将用户会话中保存的旧的令牌进行替换。这样如果用户回退到刚才的提交页面并再次 提交的话，客户端传过来的令牌就和服务器端的令牌不一致，从而有效地防止了重复提交的发生。 if (isTokenValid(request, true)) { // your code here return mapping.findForward(&success&); } else { saveToken(request); return mapping.findForward(&submitagain&); } Struts根据用户会话ID和当前系统时间来生成一个唯一（对于每个会话）令牌的，具体实现可以参考 TokenProcessor类中的generateToken()方法。 1. //验证事务控制令牌,&html:form &会自动根据session中标识生成一个隐含input代表令牌，防止两次提交 2. 在action中： //&input type=&hidden& name=&org.apache.struts.taglib.html.TOKEN& // value=&6aafd996c4cae&& if (!isTokenValid(request)) errors.add(ActionErrors.GLOBAL_ERROR, new ActionError(&error.transaction.token&)); resetToken(request); //删除session中的令牌 3. action有这样的一个方法生成令牌 protected String generateToken(HttpServletRequest request) { HttpSession session = request. getSession_r(); try { byte id[] = session. getId_r(). getBytes_r(); byte now[] = new Long(System.currentTimeMillis()).toString(). getBytes_r(); MessageDigest md = MessageDigest. getInstance_r(&MD5&); md.update(id); md.update(now); return (toHex(md.digest())); } catch (IllegalStateException e) { return (null); } catch (NoSuchAlgorithmException e) { return (null); } } 总结 对于重复提交、重复刷新、防止后退等等都是属于系统为避免重复记录而需要解决的问题，在客户端去处理需要针对每一种的可能提出相应的解决方案，然而在服务器端看来只不过是对于数据真实性的检验问题，基于令牌的处理就是一劳永逸的方法。 同时我们也看到，从不同的角度去看待问题，其解决的方法也是不同的。客户端更追求的是用户的操作，而服务端则将注意力放在了数据的处理上，所以在某个对于服务器端看似容易的问题上，用客户端来解决却麻烦了很多！反之依然。所以在某些问题的处理上我们需要综合考虑和平衡，是用客户端来解决？还是用服务器端来处理？ &网页防刷新重复提交、防后退解决方法 提交后禁用提交按钮（大部分人都是这样做的） 如果客户提交后,按F5刷新怎么办? 使用Session 在提交的页面也就是数据库处理之前： if session(&ok&)=true then response.write &错误，正在提交& response.end end if 数据处理完后，修改session(&ok&)=false。 数据处理成功马上Redirect到另外一个页面 操作后刷新的确是个问题，你可以使用跳转页面、关闭本页面，如果是有参数据条件来控制的，那就应该好做了，可以直接修改window.location的值，把参数全部改掉，这样就差不多了。 缺点：简单地运用Response.Redirect将不再有效，因为用户从一个页面转到另一个页面，我们都必须用客户端代码清除location.history。注意，这种方法清除的是最后一个访问历史记录，而不是全部的访问记录。点击后退按钮，再点击后退按钮，你可以看到这时打开的是本页面之前的页面！（当然，这是在你的客户端启用了JavaScript功能的条件下。） 如果客户按后退，怎么办？ 防止网页后退--禁止缓存 我们在进行数据库添加操作的时候，如果允许后退，而正巧有刷新了页面，就会再次执行添加操作，无疑这不是我们需要的，像一般网上很多禁止缓存的代码，有时并不可靠，这时你只要在操作的页面加上就可以了，在网页的里指定要定向的新页，再点后退，看是不是不会再退到刚才的操作页面了，实际上已经把这个历史给删除了 ASP： Response.Buffer = True Response.ExpiresAbsolute = Now() - 1 Response.Expires = 0 Response.CacheControl = &no-cache& ASP.NET： Response.Buffer= Response.ExpiresAbsolute=DateTime.Now.AddSeconds(-1); Response.Expires=0; Response.CacheControl=&no-cache&; 究竟怎样才能&禁用&浏览器的后退按钮？或者&怎样才能防止用户点击后退按钮返回以前浏览过的页面？& 遗憾的是，我们无法禁用浏览器的后退按钮。 防止网页后退--新开窗口 用window.open弹出表单页面，点提交后关闭该页；处理提交的ASP页也是用弹出，设定表单的target,点提交时window.open(&XXX.asp&,&_blank&),然后用JS来提交表单，完成后window.close()； 简单的说，就是提交表单的时候弹出新窗口，关闭本窗口。对于window.open()打开的窗口怎么后退？能后退到哪里去？ 呵呵，罗嗦了一堆废话，知道怎么处理了么？混合运用客户端脚本和服务器端脚本。 &jsp重复提交问题 看了网上的，有几种方法： 1 在你的表单页里HEAD区加入这段代码: &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 :57 GMT&& 2 生成一个令牌保存在用户session中，在form中加一个hidden域，显示该令 牌的值，form提交后重新生成一个新的令牌，将用户提交的令牌和session 中的令牌比较，如相同则是重复提交 3 在你的服务器端控件的代码中使用Response.Redirect(&selfPage&)语句。但是大多的数都不使用这种方法。 方法还有很多。。。 4 &input type=&button& value=&提交& onclick=&this.disabled=this.form.submit()&& 5 在JSP页面的FORM表单中添加一个hidden域 &input type=&hidden& name=&url&value=&%=request. getRequestURL_r()%&& 在你的serverlet中添加如下语句 String url=request. getParameter_r(&url&); response.sendRedirect(url); 我一般都是采用这样的方法返回JSP页面的,不太明白你说的重复刷新是什么概念 6 ajax 无刷新提交 7 Web开发中防止浏览器的刷新键引起系统操作重复提交 怎么解决呢？重定向可以解决页面刷新带来的数据的重复提交的问题，我们自然可以利用重定向的方式来解决这个问题。但是struts的action里面mapping.findword（）；跳转的话，默认的是在工程文件夹里面找要跳转的页面。这种情况，怎么解决呢？ 修改struts－config.xml 文件，在action里面有一个redirect重新定向的属性，struts中默认的是false，添加这个属性，改成true，在forword中写上要跳转页面的绝对或者相对地址就行了 修改如下： &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& &/action-mappings& 浏览器相关难处理的问题 浏览器的后退按钮使得我们能够方便地返回以前访问过的页面，它无疑非常有用。但有时候我们不得不关闭这个功能，以防止用户打乱预定的页面访问次序。本文介绍网络上可找到的各种禁用浏览器后退按钮方案，分析它们各自的优缺点和适用场合。 一、概述 　　 曾经有许多人问起，&怎样才能&禁用&浏览器的后退按钮？&，或者&怎样才能防止用户点击后退按钮返回以前浏览过的页面？&在ASP论坛上，这个问题也是问得最多的问题之一。遗憾的是，答案非常简单：我们无法禁用浏览器的后退按钮。 　　 起先我对于居然有人想要禁用浏览器的后退按钮感到不可思议。后来，看到竟然有那么多的人想要禁用这个后退按钮，我也就释然（想要禁用的只有后退按钮，不包括浏览器的前进按钮）。因为在默认情况下，用户提交表单之后可以通过后退按钮返回表单页面（而不是使用&编辑&按钮！），然后再次编辑并提交表单向数据库插入新的记录。这是我们不愿看到的。 　　 因此我就决定要找出避免出现这种情况的方法。我访问了许多网站，参考了这些网站所介绍的各种实现方法。如果你经常访问ASP编程网站，本文所介绍的部分内容你可能已经见到过。本文的任务是把各种可能的方法都介绍给大家，然后找出最好的方法！ 二、禁止缓存 　　 在我找到的许多方案中，其中有一种建议禁止页面缓存。具体是使用服务器端脚本，如下所示： &% Response.Buffer = True Response.ExpiresAbsolute = Now() - 1 Response.Expires = 0 Response.CacheControl = &no-cache& %& 　　 这种方法非常有效！它强制浏览器重新访问服务器下载页面，而不是从缓存读取页面。使用这种方法时，编程者的主要任务是创建一个会话级的变量，通过这个变量确定用户是否仍旧可以查看那个不适合通过后退按钮访问的页面。由于浏览器不再缓存这个页面，当用户点击后退按钮时浏览器将重新下载该页面，此时程序就可以检查那个会话变量，看看是否应该允许用户打开这个页面。 　　 例如，假设我们有如下表单： &% Response.Buffer = True Response.ExpiresAbsolute = Now() - 1 Response.Expires = 0 Response.CacheControl = &no-cache& If Len(Session(&FirstTimeToPage&)) & 0 then & 用户已经访问过当前页面，现在是再次返回访问。 & 清除会话变量，将用户重定向到登录页面。 Session(&FirstTimeToPage&) = && Response.Redirect &/Bar.asp& Response.End End If & 如果程序运行到这里，说明用户能够查看当前页面 & 以下开始创建表单 %& &form method=post action=&SomePage.asp&& &input type=submit& &/form& 　　 我们借助会话变量FirstTimeToPage检查用户是否是第一次访问当前页面。如果不是第一次（即Session(&FirstTimeToPage&)包含某个值），那么我们就清除会话变量的值，然后把用户重新定向到一个开始页面。这样，当表单提交时（此时SompePage.asp被打开），我们必须赋予FirstTimeToPage一个值。即，在SomePage.asp中我们需要加上下面的代码： Session(&FirstTimeToPage&) = &NO& 　　 这样，已经打开SomePage.asp的用户如果点击后退按钮，浏览器将重新请求服务器下载页面，服务器检查到Session(&FirstTimeToPage&)包含了一个值，于是就清除Session(&FirstTimeToPage&)，并把用户重定向到其他页面。当然，所有这一切都需要用户启用了Cookie，否则会话变量将是无效的。（有关该问题的更多说明，请参见For session ariables to work, must the Web visitor have cookies enabled?） 　　 另外，我们也可以用客户端代码使浏览器不再缓存Web页面： &html& &head& &meta http-equiv=&Expires& CONTENT=&0&& &meta http-equiv=&Cache-Control& CONTENT=&no-cache&& &meta http-equiv=&Pragma& CONTENT=&no-cache&& &/head& 　　 如果使用上面的方法强制浏览器不再缓存Web页面，必须注意以下几点： 只有在使用安全连接时&Pragma: no-cache&才防止浏览器缓存页面。对于不受安全保护的页面，&Pragma: no-cache&被视为与&Expires: -1&相同，此时浏览器仍旧缓存页面，但把页面标记为立即过期。在IE 4或5中，&Cache-Control&META HTTP-EQUIV标记将被忽略，不起作用。 　　 在实际应用中我们可以加上所有这些代码。然而，由于这种方法不能适用于所有的浏览器，所以是不推荐使用的。但如果是在Intranet环境下，管理员可以控制用户使用哪种浏览器，我想还是有人会使用这种方法。 三、其他方法 　　 接下来我们要讨论的方法以后退按钮本身为中心，而不是浏览器缓存。这儿有一篇文章Rewiring the Back Button很值得参考。不过我注意到，如果使用这种方法，虽然用户点击一下后退按钮时他不会看到以前输入数据的页面，但只要点击两次就可以，这可不是我们希望的效果，因为很多时候，固执的用户总是能够找到绕过预防措施的办法。 　　 另外一种禁用后退按钮的办法是用客户端JavaScript打开一个没有工具条的窗口，这使得用户很难返回前一页面，但不是不可能。一种更安全但相当恼人的方法是，当表单提交时打开一个新的窗口，与此同时关闭表单所在的窗口。但我觉得这种方法不值得认真考虑，因为我们总不能让用户每提交一个表单就打开一个新窗口。 　　 那么，在那个我们不想让用户返回的页面是否也可以加入JavaScript代码呢？在这个页面中加入的JavaScript代码可用来产生点击前进按钮的效果，这样也就抵消了用户点击后退按钮所产生的动作。用于实现该功能的JavaScript代码如下 所示： &script language=&JavaScript&& &!-- javascript:window.history.forward(1); //--& &/script& 　　 同样地，这种方法虽然有效，但距离&最好的方法&还差得很远。后来我又看到有人建议用location.replace从一个页面转到另一个页面。这种方法的原理是，用新页面的URL替换当前的历史纪录，这样浏览历史记录中就只有一个页面，后退按钮永远不会变为可用。我想这可能正是许多人所寻求的方法，但这种方法仍旧不是任何情况下的最好方法。使用这种方法的实例如下所示： &A HREF=&PageName.htm& onclick=&javascript:location.replace(this.href); event.returnValue=&&禁止后退到本页面的链接&/A& 　　 禁止后退到本页面的链接！ 　　 这种方法的缺点在于：简单地运用Response.Redirect将不再有效，这是因为每次用户从一个页面转到另一个页面，我们都必须用客户端代码清除location.history。另外还要注意，这种方法清除的是最后一个访问历史记录，而不是全部的访问记录。 　　 点击上面的链接，你将打开一个简单的HTML页面。再点击后退按钮，你可以看到这时打开的不是本页面，而是本页面之前的页面！（当然，你必须在浏览器中启用了客户端JavaScript代码。） 　　 经过一番仔细的寻寻觅觅之后，我发现仍旧无法找出真正能够完全禁用浏览器后退按钮的办法。所有这里介绍的方法都能够在不同程度上、以不同的方式禁止用户返回前一页面，但它们都有各自的局限。由于不存在能够完全禁用后退按钮的方法，所以最好的方案应该是：混合运用客户端脚本和服务器端脚本。 &html& &head& &meta http-equiv=&Expires& CONTENT=&0&& &meta http-equiv=&Cache-Control& CONTENT=&no-cache&& &meta http-equiv=&Pragma& CONTENT=&no-cache&& &/head& &script language=&JavaScript&& &!-- javascript:window.history.forward(1); //--& &/script& &/html& Asp.net中防刷新重复提交、防后退方法 简单操作方法防后退和刷新 Page_Load中加入 Response.Cache.SetNoStore(); //Session中存储的变量&IsSubmit&是标记是否提交成功的 if (!IsPostBack) if (Session[&IsSubmit&]==null) Session.Add(&IsSubmit&,false); if ((bool)Session[&IsSubmit&]) { //如果表单数据提交成功，就设&Session[&IsSubmit&]&为false Session[&IsSubmit&] = //显示提交成功信息 TextBox1.Text = & * 提交成功!&; } else {//否则的话（没有提交，或者是页面刷新），不显示任何信息 TextBox1.Text = &&; Response.End(); } 提交按钮中加入 Session[&IsSubmit&] = Response.Redirect (&本页&); 另外： 1、通常应该在业务层进行判断（唯一性）解决这种问题 2、要在页面装载事件写上 Response.CacheControl = &no-cache& 清除缓存 3、也有人这样说：我以前也碰到过这样的问题，是在分步提交中一个人的简历，在写完第一个页面后跳到第二个页面，为了防止用户用后退返回到第一个页面，再重新提交第一个页面，我是当用户提交第一次提交第一个页面时，把插入数据库中的记录的自增长id号放到session里，当用户从第二个页面返回到第一个页面再一次提交该页面时，我就用session里的值去数据库查，如果有这个id就用update语句把第一个页面的数据写进数据库，如果没有查到这个id,就用insert语句。
大家感兴趣的内容
12345678910
最近更新的内容jsp中Action post提交报404错误_百度知道ajax post 请求后台，提交form data的时候能进路由，可用json 数据提交就报404了，用的是express - CNode技术社区
这家伙很懒，什么个性签名都没有留下。
url 不一样？
细节呢? 有没有报错? 对应代码用了什么?
路由没有正确匹配，可以看一下
CNode 社区为国内最专业的 Node.js 开源技术社区，致力于 Node.js 的技术研究。
服务器赞助商为
，存储赞助商为
，由提供应用性能服务。
新手搭建 Node.js 服务器，推荐使用无需备案的03:21:39 UTC
服务器开启：
Access-Control-Allow-Methods:GET, PUT, POST, DELETE, OPTIONS
Access-Control-Allow-Origin:*
ajax 需要如何配置才能跨域请求？
04:57:53 UTC
你的服务端有配置该请求对应的post方法吗？
举个例子：（express）服务端：var express = require("express");var app = require("express")();
var allowCrossDomain = function(req, res, next){
res.header('Access-Control-Allow-Origin','*');
res.header('Access-Control-Allow-Methods','GET,POST,PUT');
return next();}
app.use(allowCrossDomain);
app.post('/posttest', function(req, res, next){ res.send('yes, your cross domain post is succcess');});
app.listen(8081);
客户端：function crossPostTest(){
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8081/posttest'
xhr.addEventListener('load',function(){
if(xhr.readyState === 4 && xhr.status == 200) {
console.log(xhr.responseText);
xhr.addEventListener('error', function(e){
console.log(e)
xhr.open('post', url, true);
xhr.send();}
15:46:30 UTC
有没有最终的解决方案？38164人阅读
Java开发（40）
今天在做一个HttpPost请求的时候，返回状态302，最终判断是因为HttpPost和HttpGet重定向是有区别的。
构造PostMethod之前的步骤都相同，与GetMethod一样，构造PostMethod也需要一个URI参数。
网站在做登录的时候，在创建了PostMethod的实例之后，需要给method实例填充表单 的值，在BBS的登录表单中需要有两个域，第一个是用户名（域名叫username），第二个是密码（域名叫password）。表单中的域用类 NameValuePair来表示，该类的构造函数第一个参数是域名，第二参数是该域的值；将表单所有的值设置到PostMethod中用方法 setRequestBody。另外由于BBS登录成功后会转向另外一个页面，但是HttpClient对于要求接受后继服务的请求，比如POST和 PUT，不支持自动转发，因此需要自己对页面转向做处理。
错误代码行表现为：
int statusCode = httpClient.executeMethod(postMethod);
HttpClient对于要求接受后继服务的请求，象POST和PUT等不能自动处理转发，会返回301或者302
HttpGet ge t =
HttpParams conParams = httpClient.getParams();
HttpConnectionParams.setConnectionTimeout(conParams, timeout);
HttpConnectionParams.setSoTimeout(conParams, 600000);
HttpResponse response=
&& &get=new HttpGet(url);
&& &response = httpClient.execute(get);
&& &response.getStatusLine().getStatusCode()
} catch (Exception e) {
&& &e.printStackTrace();
HttpGet可以支持获取重定向的内容，重定向成功
response.getStatusLine().getStatusCode()返回200
如果换成了HttpPost
response.getStatusLine().getStatusCode()返回302
======================================================================
下面附上HTTP 1.1协议的详解
======================================================================
完整的 HTTP 1.1规范说明书来自于RFC 2616，你可以在http://www.rfc-editor.org/在线查阅。HTTP 1.1的状态码被标记为新特性，因为许多浏览器只支持 HTTP 1.0。你应只把状态码发送给支持 HTTP 1.1的客户端，支持协议版本可以通过调用request.getRequestProtocol来检查。
本部分余下的内容会详细地介绍 HTTP 1.1中的状态码。这些状态码被分为五大类：
100-199 用于指定客户端应相应的某些动作。
200-299 用于表示请求成功。
300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。
400-499 用于指出客户端的错误。
500-599 用于支持服务器错误。
HttpServletResponse中的常量代表关联不同标准消息的状态码。在servlet程序中，你会更多地用到这些常量的标识来使用状态码。例如：你一般会使用response.setStatus(response.SC_NO_CONTENT)而不是 response.setStatus(204)，因为后者不易理解而且容易导致错误。但是，你应当注意到服务器允许对消息轻微的改变，而客户端只注意状态码的数字值。所以服务器可能只返回 HTTP/1.1 200 而不是 HTTP/1.1 200 OK。
100 (Continue/继续)
如果服务器收到头信息中带有100-continue的请求，这是指客户端询问是否可以在后续的请求中发送附件。在这种情况下，服务器用100(SC_CONTINUE)允许客户端继续或用417 (Expectation Failed)告诉客户端不同意接受附件。这个状态码是 HTTP 1.1中新加入的。
101 (Switching Protocols/转换协议)
101 (SC_SWITCHING_PROTOCOLS)状态码是指服务器将按照其上的头信息变为一个不同的协议。这是 HTTP 1.1中新加入的。
200 (OK/正常)
200 (SC_OK)的意思是一切正常。一般用于相应GET和POST请求。这个状态码对servlet是缺省的；如果没有调用setStatus方法的话，就会得到200。
201 (Created/已创建)
201 (SC_CREATED)表示服务器在请求的响应中建立了新文档；应在定位头信息中给出它的URL。
202 (Accepted/接受)
202 (SC_ACCEPTED)告诉客户端请求正在被执行，但还没有处理完。
203 (Non-Authoritative Information/非官方信息)
状态码203 (SC_NON_AUTHORITATIVE_INFORMATION)是表示文档被正常的返回，但是由于正在使用的是文档副本所以某些响应头信息可能不正确。这是 HTTP 1.1中新加入的。
204 (No Content/无内容)
在并没有新文档的情况下，204 (SC_NO_CONTENT)确保浏览器继续显示先前的文档。这各状态码对于用户周期性的重载某一页非常有用，并且你可以确定先前的页面是否已经更新。例如，某个servlet可能作如下操作：
int pageVersion =Integer.parseInt(request.getParameter(&pageVersion&));
if (pageVersion &;= currentVersion) {
&& response.setStatus(response.SC_NO_CONTENT);
&&&&&& // Create regular page
但是，这种方法对通过刷新响应头信息或等价的HTML标记自动重载的页面起作用，因为它会返回一个204状态码停止以后的重载。但基于JavaScript脚本的自动重载在这种情况下仍然需要能够起作用。可以阅读本书7.2 ( HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1响应头信息以及他们的意义)部分的详细讨论。
205 (Reset Content/重置内容)
重置内容205 (SC_RESET_CONTENT)的意思是虽然没有新文档但浏览器要重置文档显示。这个状态码用于强迫浏览器清除表单域。这是 HTTP 1.1中新加入的。
206 (Partial Content/局部内容)
206 (SC_PARTIAL_CONTENT)是在服务器完成了一个包含Range头信息的局部请求时被发送的。这是 HTTP 1.1中新加入的。
300 (Multiple Choices/多重选择)
300 (SC_MULTIPLE_CHOICES)表示被请求的文档可以在多个地方找到，并将在返回的文档中列出来。如果服务器有首选设置，首选项将会被列于定位响应头信息中。
301 (Moved Permanently)
301 (SC_MOVED_PERMANENTLY)状态是指所请求的文档在别的地方；文档新的URL会在定位响应头信息中给出。浏览器会自动连接到新的URL。
302 (Found/找到)
与301有些类似，只是定位头信息中所给的URL应被理解为临时交换地址而不是永久的。注意：在 HTTP 1.0中，消息是临时移动(Moved Temporarily)的而不是被找到，因此HttpServletResponse中的常量是SC_MOVED_TEMPORARILY不是我们以为的SC_FOUND。
代表状态码302的常量是SC_MOVED_TEMPORARILY而不是SC_FOUND。
状态码302是非常有用的因为浏览器自动连接在定为响应头信息中给出的新URL。这非常有用，而且为此有一个专门的方法——sendRedirect。使用response.sendRedirect(url)比调用response.setStatus(response.SC_MOVED_TEMPORARILY)和response.setHeader(&Location&, url)多几个好处。首先，response.sendRedirect(url)方法明显要简单和容易。第二，servlet自动建立一页保存这一连接以提供给那些不能自动转向的浏览器显示。最后，在servlet
2.2版本（J2EE中的版本）中，sendRedirect能够处理相对路径，自动转换为绝对路径。但是你只能在2.1版本中使用绝对路径。
如果你将用户转向到站点的另一页中，你要用 HttpServletResponse 中的 encodeURL 方法传送URL。这么做可预防不断使用基于URL重写的会话跟踪的情况。URL重写是一种在你的网站跟踪不使用 cookies 的用户的方法。这是通过在每一个URL尾部附加路径信息实现的，但是 servlet 会话跟踪API会自动的注意这些细节。会话跟踪在第九章讨论，并且养成使用 encodeURL 的习惯会使以后添加会话跟踪的功能更容易很多。
如果你将用户转向到你的站点的其他页面，用 response.sendRedirect(response.encodeURL(url)) 的方式事先计划好会话跟踪(session tracking)要比只是调用 response.sendRedirect(url) 好的多。
这个状态码有时可以与301交换使用。例如，如果你错误的访问了http://host/~user（路径信息不完整），有些服务器就会回复301状态码而有些则回复302。从技术上说，如果最初的请求是GET浏览器只是被假定自动转向。如果想了解更多细节，请看状态码307的讨论。
303 (See Other/参见其他信息)
这个状态码和 301、302 相似，只是如果最初的请求是 POST，那么新文档（在定位头信息中给出）药用 GET 找回。这个状态码是新加入 HTTP 1.1中的。
304 (Not Modified/为修正)
当客户端有一个缓存的文档，通过提供一个 If-Modified-Since 头信息可指出客户端只希望文档在指定日期之后有所修改时才会重载此文档，用这种方式可以进行有条件的请求。304 (SC_NOT_MODIFIED)是指缓冲的版本已经被更新并且客户端应刷新文档。另外，服务器将返回请求的文档及状态码 200。servlet一般情况下不会直接设置这个状态码。它们会实现getLastModified方法并根据修正日期让默认服务方法处理有条件的请求。这个方法的例程已在2.8部分(An Example Using Servlet
Initialization and Page Modification Dates/一个使用servlet初始化和页面修正日期的例子)给出。
305 (Use Proxy/使用代理)
305 (SC_USE_PROXY)表示所请求的文档要通过定位头信息中的代理服务器获得。这个状态码是新加入 HTTP 1.1中的。
307 (Temporary Redirect/临时重定向)
浏览器处理307状态的规则与302相同。307状态被加入到 HTTP 1.1中是由于许多浏览器在收到302响应时即使是原始消息为POST的情况下仍然执行了错误的转向。只有在收到303响应时才假定浏览器会在POST请求时重定向。添加这个新的状态码的目的很明确：在响应为303时按照GET和POST请求转向；而在307响应时则按照GET请求转向而不是POST请求。注意：由于某些原因在HttpServletResponse中还没有与这个状态对应的常量。该状态码是新加入HTTP 1.1中的。
在 HttpServletResponse 中没有 SC_TEMPORARY_REDIRECT 常量，所以你只能显示的使用307状态码。
400 (Bad Request/错误请求)
400 (SC_BAD_REQUEST)指出客户端请求中的语法错误。
401 (Unauthorized/未授权)
401 (SC_UNAUTHORIZED)表示客户端在授权头信息中没有有效的身份信息时访问受到密码保护的页面。这个响应必须包含一个WWW-Authenticate的授权信息头。例如，在本书4.5部分中的“Restricting Access to Web Pages./限制访问Web页。”
403 (Forbidden/禁止)
403 (SC_FORBIDDEN)的意思是除非拥有授权否则服务器拒绝提供所请求的资源。这个状态经常会由于服务器上的损坏文件或目录许可而引起。
404 (Not Found/未找到)
404 (SC_NOT_FOUND)状态每个网络程序员可能都遇到过，他告诉客户端所给的地址无法找到任何资源。它是表示“没有所访问页面”的标准方式。这个状态码是常用的响应并且在HttpServletResponse类中有专门的方法实现它：sendError(&message&)。相对于setStatus使用sendError得好处是：服务器会自动生成一个错误页来显示错误信息。但是，Internet Explorer 5浏览器却默认忽略你发挥的错误页面并显示其自定义的错误提示页面，虽然微软这么做违反了 HTTP
规范。要关闭此功能，在工具菜单里，选择Internet选项，进入高级标签页，并确认“显示友好的 HTTP 错误信息”选项（在我的浏览器中是倒数第8各选项）没有被选。但是很少有用户知道此选项，因此这个特性被IE5隐藏了起来使用户无法看到你所返回给用户的信息。而其他主流浏览器及IE4都完全的显示服务器生成的错误提示页面。可以参考图6-3及6-4中的例子。
默认情况下，IE5忽略服务端生成的错误提示页面。
405 (Method Not Allowed/方法未允许)
405 (SC_METHOD_NOT_ALLOWED)指出请求方法(GET, POST, HEAD, PUT, DELETE, 等)对某些特定的资源不允许使用。该状态码是新加入 HTTP 1.1中的。
406 (Not Acceptable/无法访问)
406 (SC_NOT_ACCEPTABLE)表示请求资源的MIME类型与客户端中Accept头信息中指定的类型不一致。见本书7.2部分中的表7.1(HTTP 1.1 Response Headers and Their Meaning/HTTP 1.1响应头信息以及他们的意义)中对MIME类型的介绍。406是新加入 HTTP 1.1中的。
407 (Proxy Authentication Required/代理服务器认证要求)
407 (SC_PROXY_AUTHENTICATION_REQUIRED)与401状态有些相似，只是这个状态用于代理服务器。该状态指出客户端必须通过代理服务器的认证。代理服务器返回一个Proxy-Authenticate响应头信息给客户端，这会引起客户端使用带有Proxy-Authorization请求的头信息重新连接。该状态码是新加入 HTTP 1.1中的。
408 (Request Timeout/请求超时)
408 (SC_REQUEST_TIMEOUT)是指服务端等待客户端发送请求的时间过长。该状态码是新加入 HTTP 1.1中的。
409 (Conflict/冲突)
该状态通常与PUT请求一同使用，409 (SC_CONFLICT)状态常被用于试图上传版本不正确的文件时。该状态码是新加入 HTTP 1.1中的。
410 (Gone/已经不存在)
410 (SC_GONE)告诉客户端所请求的文档已经不存在并且没有更新的地址。410状态不同于404，410是在指导文档已被移走的情况下使用，而404则用于未知原因的无法访问。该状态码是新加入 HTTP 1.1中的。
411 (Length Required/需要数据长度)
411 (SC_LENGTH_REQUIRED)表示服务器不能处理请求（假设为带有附件的POST请求），除非客户端发送Content-Length头信息指出发送给服务器的数据的大小。该状态是新加入 HTTP 1.1的。
412 (Precondition Failed/先决条件错误)
412 (SC_PRECONDITION_FAILED)状态指出请求头信息中的某些先决条件是错误的。该状态是新加入 HTTP 1.1的。
413 (Request Entity Too Large/请求实体过大)
413 (SC_REQUEST_ENTITY_TOO_LARGE)告诉客户端现在所请求的文档比服务器现在想要处理的要大。如果服务器认为能够过一段时间处理，则会包含一个Retry-After的响应头信息。该状态是新加入 HTTP 1.1的。
414 (Request URI Too Long/请求URI过长)
414 (SC_REQUEST_URI_TOO_LONG)状态用于在URI过长的情况时。这里所指的“URI”是指URL中主机、域名及端口号之后的内容。例如：在URL--http://www.:8080/we/look/silly/now/中URI是指/we/look/silly/now/。该状态是新加入 HTTP 1.1的。
415 (Unsupported Media Type/不支持的媒体格式)
415 (SC_UNSUPPORTED_MEDIA_TYPE)意味着请求所带的附件的格式类型服务器不知道如何处理。该状态是新加入 HTTP 1.1的。
416 (Requested Range Not Satisfiable/请求范围无法满足)
416表示客户端包含了一个服务器无法满足的Range头信息的请求。该状态是新加入 HTTP 1.1的。奇怪的是，在servlet 2.1版本API的HttpServletResponse中并没有相应的常量代表该状态。
在servlet 2.1的规范中，类HttpServletResponse并没有SC_REQUESTED_RANGE_NOT_SATISFIABLE 这样的常量，所以你只能直接使用416。在servlet 2.2版本之后都包含了此常量。
417 (Expectation Failed/期望失败)
如果服务器得到一个带有100-continue值的Expect请求头信息，这是指客户端正在询问是否可以在后面的请求中发送附件。在这种情况下，服务器也会用该状态(417)告诉浏览器服务器不接收该附件或用100 (SC_CONTINUE)状态告诉客户端可以继续发送附件。该状态是新加入 HTTP 1.1的。
500 (Internal Server Error/内部服务器错误)
500 (SC_INTERNAL_SERVER_ERROR) 是常用的“服务器错误”状态。该状态经常由CGI程序引起也可能（但愿不会如此！）由无法正常运行的或返回头信息格式不正确的servlet引起。
501 (Not Implemented/未实现)
501 (SC_NOT_IMPLEMENTED)状态告诉客户端服务器不支持请求中要求的功能。例如，客户端执行了如PUT这样的服务器并不支持的命令。
502 (Bad Gateway/错误的网关)
502 (SC_BAD_GATEWAY)被用于充当代理或网关的服务器；该状态指出接收服务器接收到远端服务器的错误响应。
503 (Service Unavailable/服务无法获得)
状态码503 (SC_SERVICE_UNAVAILABLE)表示服务器由于在维护或已经超载而无法响应。例如，如果某些线程或数据库连接池已经没有空闲则servlet会返回这个头信息。服务器可提供一个Retry-After头信息告诉客户端什么时候可以在试一次。
504 (Gateway Timeout/网关超时)
该状态也用于充当代理或网关的服务器；它指出接收服务器没有从远端服务器得到及时的响应。该状态是新加入 HTTP 1.1的。
505 (HTTP Version Not Supported/不支持的 HTTP 版本)
505 (SC_HTTP_VERSION_NOT_SUPPORTED)状态码是说服务器并不支持在请求中所标明 HTTP 版本。该状态是新加入 HTTP 1.1的。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1549267次
积分：15422
积分：15422
排名：第496名
原创：237篇
转载：39篇
译文：10篇
评论：593条
文章：22篇
阅读：216079
(2)(10)(12)(10)(25)(17)(17)(10)(13)(21)(12)(5)(1)(9)(4)(6)(8)(2)(3)(2)(5)(2)(6)(4)(2)(1)(2)(1)(2)(1)(7)(14)(7)(5)(3)(1)(2)(19)(9)(3)}