Post/Redirect/Get模式防止表單重複提交

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