Spring MVC 請求路徑遇到的302問題的解決方法

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響應時應當做的。