有這樣一個案例，你通過配置tomcat的虛擬目錄，將預設訪問介面由tomcat介面改為你的網站介面。當你採用虛擬目錄訪問你的網站時，報500錯誤。但是當你不是通過虛擬目錄，而是直接訪問資源的話，錯誤消失。這是我在專案中遇到的一個bug,並最終解決，分享所得。

    我採用代理軟體fiddler來排查錯誤，這款軟體可以監視HTTP請求響應中的變化。當採用域名訪問時，請求訊息頭如下所示：

    效應訊息頭為：

    從請求響應資訊對比可以看到，請求時沒有攜帶會話cookie資訊，所以響應返回一個會話Cookie。這是第一次訪問，這是正確的現象。

    響應訊息頭如下所示：

    請求訊息頭帶有會話Cookie資訊，以便讓伺服器端知道這道那個session和這個請求匹配。但是奇怪的是，似乎伺服器端並不領情，不識別這個ID，而是又建立了一個會話Cookie。再細心觀察一下，你會發現兩次會話Cookie的path屬性不一樣。到此就豁然開朗了。因為服務端完成會話（session）身份匹配時，不僅檢查ID值是否一樣，還要檢查path是否一樣，再說徹底一點，同樣的域名，“/project1”的程式不能呼叫訪問"/project2"網站所產生的會話內容。這樣才不至於部署在同一伺服器下的專案session發生串擾。

    後來發現有人在index.jsp頁面中，將某些資訊放入Session中，想法是：首頁是每個人都要訪問的，這樣不就保證在進行其他操作前將bean初始化了嗎？當採用虛擬目錄配置，就是行不通。話說回來，這樣設定會話本身是很不規範的，出錯又能怪誰了。所以，初學者切記不能為了解決目前的問題，而置一些變成程式設計規範不顧，要知道這些規範是多少前輩被bug折磨得死去活來才領悟出來的結晶。後學者又何必重蹈覆轍呢。

    最後，養成良好的程式設計習慣是非常有必要的。