tomcat虚拟目录的陷阱(不同的访问方式，不一样的结果)

有这样一个案例，你通过配置tomcat的虚拟目录，将默认访问界面由tomcat界面改为你的网站界面。当你采用虚拟目录访问你的网站时，报500错误。但是当你不是通过虚拟目录，而是直接访问资源的话，错误消失。这是我在项目中遇到的一个bug,并最终解决，分享所得。

情形是这样的，当我通过http://ictis.whut.edu.cn访问我们的网站时，如下所示：



然后，当我们url输入为：http://ictis.whut.edu.cn/ictis/时，异常消失。

我采用代理软件fiddler来排查错误，这款软件可以监视HTTP请求响应中的变化。当采用域名访问时，请求消息头如下所示：



效应消息头为：



从请求响应信息对比可以看到，请求时没有携带会话cookie信息，所以响应返回一个会话Cookie。这是第一次访问，这是正确的现象。

当使用http://ictis.whut.edu.cn/ictis来访问时，请求消息头如下所示：



响应消息头如下所示：



请求消息头带有会话Cookie信息，以便让服务器端知道这道那个session和这个请求匹配。但是奇怪的是，似乎服务器端并不领情，不识别这个ID，而是又创建了一个会话Cookie。再细心观察一下，你会发现两次会话Cookie的path属性不一样。到此就豁然开朗了。因为服务端完成会话（session）身份匹配时，不仅检查ID值是否一样，还要检查path是否一样，再说彻底一点，同样的域名，“/project1”的程序不能调用访问"/project2"网站所产生的会话内容。这样才不至于部署在同一服务器下的项目session发生串扰。

后来发现有人在index.jsp页面中，将某些信息放入Session中，想法是：首页是每个人都要访问的，这样不就保证在进行其他操作前将bean初始化了吗？当采用虚拟目录配置，就是行不通。话说回来，这样设置会话本身是很不规范的，出错又能怪谁了。所以，初学者切记不能为了解决目前的问题，而置一些变成编程规范不顾，要知道这些规范是多少前辈被bug折磨得死去活来才领悟出来的结晶。后学者又何必重蹈覆辙呢。

最后，养成良好的编程习惯是非常有必要的。