XX系統登錄之后，偶爾在用戶那會出現這個現象：
 
登錄的邏輯是這樣的：登陸主界面之后，在主界面html執行到最后的時候，使用windows.open打開一個彈出窗口，去服務器取一些需要的數據。
但是偶爾用戶那會出現彈出窗口又定位到登陸窗口了（summer中使用filter對請求過濾，發現沒有登陸的話會重新定位到登陸窗口）。
這里明明是的剛登陸的程序，卻出現沒有登陸的現象。。這個現象在用戶那一直就存在，一直也沒找到原因。
今天在和三期應服推廣人員的溝通中無意了解到，用戶習慣使用給登陸界面建立一個桌面快捷方式，一般操作如下：
在ie地址欄輸入“http://localhost:8080/spxt”，這個時候請求完成之后定位到了登陸頁面，但是ie地址欄已經變成
“http://localhost:8080/spxt/common/summer/jsp/login/register03.jsp;jsessionid=CA0CA7E455535994E523B01357B42214”
此時直接在這個ie窗口登陸是沒有問題的。而用戶一般都是在這個頁面點右鍵，選擇創建快捷方式，
這個時候就有一個問題，用戶的快捷方式超鏈接實際上指向的是后面那個帶有jsessionid的很長很長的url。
如果此時從桌面點擊這個超鏈接的快捷方式打開ie進行登陸，就很容易復現文章開始的那個截圖現象了，如果我修改快捷方式屬性，把超鏈接的
sessionid去掉就沒有問題了。（這里描述不是很準確，比如重啟一次tomcat的話就又不會復現了）。
后來在后臺打印每次使用的sessionid，發現如果從快捷方式登陸的話，真正的登錄session就是jsessionid所代表的那個session，而后來ajax
請求的是和服務器新建了連接，發現session沒有登陸信息就定位到登陸頁面了。

這里在服務器端“可能”是產生兩個session的概念：一個是本次真正登錄的session；另外是一個空的session。而在ajax異步請求的時候，
實際上用的就是后面這個空的session，這樣發現沒有登陸就重新定位到登陸頁面了？

后面原因的分析完全是自己的猜測，具體望大家指教一下：）

解決問題可以這樣：1、幫用戶把那個快捷方式的jsessionid去掉。
                  2、寫一個filter，對于是登陸請求的，把jsessionid去掉。

ps：以上問題對于收藏夾存在同樣問題。


看了帖子終于明白jsessionid是怎么來的了~多謝
在struts的org.apache.struts.action.RequestProcessor.processForwardConfig()中找到了如下代碼：
response.sendRedirect(response.encodeRedirectURL(uri));
不過感覺一般情況還是不要去掉jsessionid比較好，對于特殊情況的需要特殊去掉，基本還是利大于弊。