PRG（Post/Redirect/Get）

转自：PRG（Post/Redirect/Get）

摘要: Post/Redirect/Get 简称PRG，是一种用来防止表单重复提交数据的一种Web设计模式

Post/Redirect/Get 简称PRG，是一种用来防止表单重复提交数据的一种Web设计模式，典型的重复提交form内容的情况像用户刷新提交响应页面等可通过PRG模式来得到避免。

当一个表单通过HTTP POST被请求提交的时候，用户在服务器端返回响应期间如果刷新了响应页面，将会导致原始HTTP POST过来的内容重复提交，可能会导致一些不可预期的结果，比如重复提交数据

通常我们可以采用PRG模式来回避重复提交数据问题。PRG模式通过响应页面Header返回HTTP状态码进行页面跳转替代响应页面跳转过程。PRG模式流程如下图示：

HTTP 1.1 规范介绍HTTP 303U状态页进行跳转，303状态能确保会员在浏览器端安全地刷新服务器端响应，而不会引起HTTP POST请求重复提交。另外，目前很多商业网站依然继续使用HTTP 302来响应跳转，主要考虑到一些版本的浏览器不能很好地兼容HTTP1.1规范中的303状态码。

HTTP规范摘录：

302 Found

请求的资源现在临时从不同的URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求。只有在Cache-Control或Expires中进行了指定的情况下，这个响应才是可缓存的。

新的临时性的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。

如果这不是一个GET或者HEAD请求，那么浏览器禁止自动进行重定向，除非得到用户的确认，因为请求的条件可能因此发生变化。

注意：虽然RFC 1945和RFC 2068规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将302响应视作为303响应，并且使用GET方式访问在Location中规定的URI，而无视原先请求的方法。状态码303和307被添加了进来，用以明确服务器期待客户端进行何种反应。

303 See Other

对应当前请求的响应可以在另一个URI上被找到，而且客户端应当采用GET的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的POST请求输出重定向到一个新的资源。这个新的URI不是原始资源的替代引用。同时，303响应禁止被缓存。当然，第二个请求（重定向）可能被缓存。

新的URI应当在响应的Location域中返回。除非这是一个HEAD请求，否则响应的实体中应当包含指向新的URI的超链接及简短说明。

注意：许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动，302状态码应该可以胜任，因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。

值得注意的是，PRG设计模式并不能适用所有的表单重复提交情况，如以下几种情况：

1. 如果用户返回表单页面，重新提交表单的情况

2. 用户在服务器端响应到达之前，多次点击提交按钮的时候。(可通过JavaScript控制提交按钮点击次数)

3. 由于服务器响应缓慢，用户刷新提交POST请求造成的多次POST请求

4. 恶意用户避开客户端预防多次提交手段，进行重复提交请求

除了PRG设计模式外，另外还有一些其他技术被用在防止表单重复提交的情况下，如客户端我们可以采取JavaScript防止用户多次点击提交按钮，还可以采用Session记录用户当前提交行为等。

引用：http://en.wikipedia.org/wiki/Post/Redirect/Get

spring MVC 实现PRG请参考：http://www.javacodebook.com/2013/08/20/post-redirect-get-pattern-in-spring-mvc/