此次掛接使用者中心，互動大都通過重定向（ redirect ）實現。期間也遇到了一些問題，總結如下。
redirect原理及使用
1． 重定向原理
重定向方式是在客戶端作的重定向處理。該方法通過修改 http 協議的 header 部分 , 對瀏覽器下達重定向指令的，讓瀏覽器對在 location 中指定的 url 提出請求，使瀏覽器顯示重定向網頁的內容。
該方法可以接受絕對的或相對的 urls 。如果傳遞到該方法的引數是乙個相對的 url ，那麼 web container 在將它傳送到客戶端前會把它轉換成乙個絕對的 url 。
2． sendredirect 可以將頁面跳轉到任何頁面，不一定侷限於本 web 應用中。用法如下：
response.sendredirect("/login.jsp");
response.sendredirect("");
3． 跳轉後瀏覽器位址列變化。
4． 這種方式要傳值出去的話，只能在 url 中帶 parameter 或者放在 session 中，無法使用 request.setattribute 來傳遞。
redirect vs forward
1． forward 重定向是在容器內部實現的同乙個 web 應用程式的重定向，所以 forward 方法只能重定向到同乙個 web 應用程式中的乙個資源，重定向後瀏覽器位址列 url 不變，而 sendredirect 方法可以重定向到任何 url ，因為這種方法是修改 http 頭來實現的， url 沒什麼限制，重定向後瀏覽器位址列 url 改變。
3． 基於第二點，引數的傳遞方式不一樣。 forward 的 form 引數跟著傳遞，所以在第二個例項中可以取得 http 請求的引數。 sendredirect 只能通過鏈結傳遞引數， response.sendredirect(「login.jsp?param1=a」) 。
ajax請求處理重定向
對於 ajax 請求，客戶端不會處理該 302 的重定向請求，即頁面無響應。
當我們請求發生在伺服器 session 失效下，伺服器自動 302 到登入頁面，那我們非同步獲取的是登入頁面的資料。事實上，並沒有發生失敗事件，瀏覽器會再發一次 ajax 請求到 302 的位址，如果還是發生 302 ，一直請求，直到完成請求或者請求跨域失敗為止。對於 js 來說， 301 302 這種跳轉是透明的，無法處理。
那到底如何當 ajax 正確處理 302 呢，這是瀏覽器級別的問題，也就是說沒有瀏覽器能正確處理 302 。
對於我們前端來說，正確的驗證 ajax 回來的資料，並給出提示，那也不友好（比如伺服器端希望我們去登入頁面）。更友好的處理是當伺服器端發生 302 ，那 ajax 就當 " 錯誤 " 處理，也做 302 跳轉。
後一種修改方式（某產品線目前所採用的方案）即向 ajax 中新增對 302 的處理。這需要修改 common.js 中 ajax 類，以及 dwr 源**，新增對 302 重定向的處理（跳轉到登陸頁）。
xml.onreadystatechange = function() else if
。。。
}
重定向Redirect 的常識
今天下班的時候看到了一些重定向的基礎知識，也算開了眼界。以前也經常使用301和302，但從來沒有使用過和了解過其他的3xx的狀態碼，發現原來裡面涉及的知識和解決的問題的還不少。瀏覽器首先訪問伺服器a的url，伺服器a返回帶著location為b的url的 header 和3xx的狀態碼，瀏覽器讀取響...
重定向Redirect 的知識
今天下班的時候看到了一些重定向的基礎知識，也算開了眼界。以前也經常使用301和302，但從來沒有使用過和了解過其他的3xx的狀態碼，發現原來裡面涉及的知識和解決的問題的還不少。瀏覽器首先訪問伺服器a的url，伺服器a返回帶著location為b的url的 header 和3xx的狀態碼，瀏覽器讀取響...
認識Linux資料重定向redirection
今天kiddd帶大家學習的是linux的乙個知識內容 redirection，重定向。了解重定向之前首先需要知道linux的三種檔案描述符。當我們正常執行linux命令時，linux命令行會將命令寫入後的輸出，寫入到標準輸出檔案當中，並將輸出的結果列印到螢幕上，如 這種檔案叫做標準輸出檔案，它到檔案...